- Tricky ... - 9 Updates
- Global const objects missing from object file - 2 Updates
- How to get mantissa of long double? - 7 Updates
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 07 11:27PM > limit on how many times try_lock() can be called. Akin to an adaptive mutex, > except instead of spinning, we see if something else can be done. > It does work in certain scenarios and/or setups... You have *understanding* :P Thanks! -- 7-77-777 Evil Sinner! with software, you repeat same experiment, expecting different results... |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 07:52AM +0200 Am 07.10.2021 um 21:21 schrieb Chris M. Thomasson: > I am saying the fast-path is lock/wait-free. No one calls sth. with a fast path and a slow path lock-free. Lock-free is _only_ without a slow path. Idiot ! |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 07:53AM +0200 Am 07.10.2021 um 21:26 schrieb Chris M. Thomasson: >> Lock-free algorithms don't have a slow path. >> That's while they don't lock and you've to poll them. > Why poll them? ... Because they are lock-free. > Add a slow-path using futex or eventcount... Then they aren't lock-free anymore. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 08 12:53PM -0700 On 10/7/2021 10:53 PM, Bonita Montero wrote: >>> That's while they don't lock and you've to poll them. >> Why poll them? ... > Because they are lock-free. Sigh... Polling is inefficient waiting, in a sense. Anyway... >> Add a slow-path using futex or eventcount... > Then they aren't lock-free anymore. Oh well. I tried everybody. She does not seem to get it. Shit happens. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 08 12:56PM -0700 On 10/7/2021 10:52 PM, Bonita Montero wrote: >> I am saying the fast-path is lock/wait-free. > No one calls sth. with a fast path and a slow path lock-free. > Lock-free is _only_ without a slow path. Idiot ! Sigh. Never mind. I am casting my pearls before, well, whatever. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 08 01:05PM -0700 On 10/3/2021 9:44 PM, Branimir Maksimovic wrote: >> http://fractallife247.com/test/webgl/ >> Does it work for you? Thanks. > Both work on Safari, thanks. I am glad they work for you! Thanks for taking the time to give them a go. Now, I am wondering if the following program of mine works on Safari on your end. Iirc, it works on Safari for windows... ;^) Its a highly experimental field based DLA algorihtm I created. Let it run for around a half a minute or so. Then try to click around in the field, and see what happens... A click should create a new attractor and start influencing the field in real time. Keep in mind that the particles are following field lines instead of using random walks. This is different than "traditional" DLA: http://fractallife247.com/fdla/ Fwiw, here is a decent description of DLA: https://en.wikipedia.org/wiki/Diffusion-limited_aggregation Thanks. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 08 01:13PM -0700 On 10/6/2021 8:24 PM, Branimir Maksimovic wrote: > it would probably work, but I have tried to do it in HLL :P > This is M1, but I think it is more related to OS... > Haven't tried C++ though :P Try to get a disassembly of std::atomic<T>::compare_exchange_weak() on your system. Start with an unsigned int. I am interested! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 08 02:07PM -0700 On 10/7/2021 2:26 AM, Ian Collins wrote: >> https://www.youtube.com/watch?v=nPR4xK-5i4I >> Both links work for me. How many work for you? Just wondering. > Cool! Thanks Ian! Fwiw, when you get some time to kill, check this older image out: http://siggrapharts.ning.com/photo/heavenly-visions Its from one of my experimental IFS's. One of my friends wrote about some of its inner workings here: http://paulbourke.net/fractals/multijulia/ I have it coded up in C++. :^) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 08 03:24PM -0700 On 10/7/2021 2:27 PM, Chris M. Thomasson wrote: > if (! try_to_do_something_else()) > { > lock(); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Oh crap. I did not mean to imply recursion here! Let me fix that: __________________________ void my_custom_lock() { while (! try_lock()) { if (! try_to_do_something_else()) { lock(); break; } } } __________________________ There, now there is no possibility of recursion in my pseudo-code. Sorry for any confusion! Ouch! ;^o |
| Steve Keller <keller.steve@gmx.de>: Oct 08 10:47PM +0200 I am surprised I cannot define a global const object in one file and access it in another: --------- x.cc --------- const int a = 42 ------------------------ --------- y.cc --------- extern const int a; int foo() { return a; } ------------------------ When I compile both sources to objects I see access to 'a' as expected: movl a(%rip), %eax ret But the object file x.o does not contain anything. Why? If I remove the 'const' in the definition and in the extern declaration it works as expected. Also if add an 'extern' to the definition in x.cc so that it is extern const int a = 42; the object 'a' is created in x.o. Can someone explain this? Steve |
| red floyd <no.spam.here@its.invalid>: Oct 08 03:09PM -0700 On 10/8/2021 1:47 PM, Steve Keller wrote: > definition in x.cc so that it is > extern const int a = 42; > the object 'a' is created in x.o. Can someone explain this? Const objects have internal linkage unless it is specified with "extern". I think it's in 6.2.1 in C++17, but I won't swear to it. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 08 04:37AM >> same byte order as the members of the struct. It also assumes that the long >> double occupies exactly 10 bytes and isn't padded in the wrong end. > It actually fits for all x86-compilers. ARM is becoming more and more common. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 08 04:39AM > (And if anyone tells you type-punning unions "work" in C++, then ask why > std::bit_cast<> was added to the language.) Why hasn't type-punning been standardized in C++, given that it's standardized in C? |
| red floyd <no.spam.here@its.invalid>: Oct 07 10:44PM -0700 On 10/6/2021 11:38 PM, Bonita Montero wrote: >> long >> double occupies exactly 10 bytes and isn't padded in the wrong end. > It actually fits for all x86-compilers. Back in the early '80s, there was something called "all-the-world's- a-vax-running-BSD Syndrome". You appear to have the modern variant, known as "All-the-world's-an-x86-running-Windows Syndrome." |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 07:54AM +0200 Am 08.10.2021 um 06:37 schrieb Juha Nieminen: >>> double occupies exactly 10 bytes and isn't padded in the wrong end. >> It actually fits for all x86-compilers. > ARM is becoming more and more common. ARM hasn't 80 bit FP, so there's no need for the above code on ARM. |
| David Brown <david.brown@hesbynett.no>: Oct 08 09:25AM +0200 On 08/10/2021 06:39, Juha Nieminen wrote: >> std::bit_cast<> was added to the language.) > Why hasn't type-punning been standardized in C++, given that it's > standardized in C? That's a fair question. First, I think you'd have to ask why was it standardised in C? AFAIUI (and this is from memory rather than reference), in C90 and before, it was quite unclear whether the standards defined type-punning union behaviour. However, code relied on it. It's not something that turns up very often - you very rarely have need for this kind of thing. But because it turns up in low-level code that is in turn used by lots of other code - such as in the heart of a software floating point library - it becomes important. A few compilers, such as gcc, actually documented that type-punning unions worked - most did not, though people expected them to support them. I've never been clear as to whether the C standards committee changed their mind to make type-punning fully defined, or if they simply changed the wording of the standard to make it less ambiguous. In C++, however, the idea of type-punning did not fit in. The original aim was that most C++ code would be about objects that get created using a constructor, maintain an invariant by using methods to access the private data, and get destroyed cleanly with a destructor. Messing directly with the internals of an object using different types - that's the kind of bad behaviour C programmers use, and stops you relying on your types and their safety and correctness. C++ certainly could have made it defined behaviour for unions that are limited to POD types. But they have never done so - maybe there are complicating factors that I haven't thought of. The current idea in C++20 is std::bit_cast<>. I don't know how useful or convenient that will be. |
| scott@slp53.sl.home (Scott Lurndal): Oct 08 02:34PM David Brown <david.brown@hesbynett.no> writes: . >them. I've never been clear as to whether the C standards committee >changed their mind to make type-punning fully defined, or if they simply >changed the wording of the standard to make it less ambiguous. Reading through the Unisys C compiler manual is interesting, due to the radically different underlying architecture, for example in the porting section: The comparison of negative numbers with unsigned types may behave differently on A Series systems than on other platforms. Platforms that store arithmetic values in one's or two's complement form store the sign when assigning to an unsigned type. On A Series systems, the sign is not stored when assigning to an unsigned type. On A Series systems, comparing a negative value with the value in an unsigned type will never be true unless the CHAR2 or UNSIGNED subordinate options of the PORT compiler control option are used to emulate two's complement arithmetic on unsigned types. Another workaround is to change negative literals to their one's complement values (for example, -1 becomes 0xFF). The representation of scalar types differs between A Series systems and other platforms. On A Series systems, integer types are 6-bytes in length and start on word boundaries. Any calculations that assume the size of an integer type to be anything other than 6 bytes will result in problems when portation occurs. long Ary[ (sizeof(SomeObject)+3) / sizeof(long)]; The addition of the numeric literal 3 to the size of the type of SomeObject assumes that sizeof(long) returns 4. In A Series C, sizeof(long) returns 6, causing the calculation to return unexpected results. The following code fragment illustrates how you can avoid this type of portation problem: struct{ unsigned short Type; unsigned char SeqNum; } Info; char *InfoPtr = &Info; seq = InfoPtr[2]; Using InfoPtr[2] to access SeqNum assumes that bytes 0 and 1 contain the structure member Type and that byte 2 contains the structure member SeqNum. On A Series systems, Type occupies bytes 0 to 5, and SeqNum occupies byte 6, which means that InfoPtr[2] accesses the wrong data. When a pointer is implicitly or explicitly cast from a pointer to an object of a given alignment to a pointer to an object of a more strict alignment, the resulting pointer may not be aligned with the original pointer. For example, casting a pointer to char to a pointer to int causes the pointer index to be divided by 6 to change from character to word units. The divide by 6 operation causes the pointer to int to point to the beginning of the word. If the char pointer points to the middle of the word, the two pointers do not point to the same data. To catch pointer alignment errors of this type at run time, use the $BOUNDS(ALIGNMENT) compiler control option. Two's complement arithmetic is used on many platforms. On A Series systems, arithmetic is performed on data in signed-magnitude form. This can cause discrepancies in algorithms that depend on the two's complement representation. For example, C applications that use encryption algorithms to match data, such as passwords, between client and server must perform the encryption the same way on the client-end and the server-end. The differences between the two's complement and signed-magnitude representation may result in different values when fragments of data are extracted, encrypted, and reinserted into the data. To obtain matching results, you can define macros that return arithmetic results in two's complement form. The following example illustrates macros for two's complement addition and subtraction: #define tc_add(arg1, arg2) (((arg1) + (arg2)) & 0xFF) #define tc_sub(arg1, arg2) (((arg1) + (0x100 - (arg2))) & 0xFF) The macro errno is defined as an array indexed by the unique stack number of the execution process when $SET CONCURRENTEXECUTION or $SHARING=SHAREDBYALL. As a result, each client of a C library has a unique errno location. [ed. Note stack number in this context is equivalent to task/process id] Although each errno location starts at zero, the location is not reset to zero when a client delinks from a library or when another client links with the same stack number. In order to avoid this issue, the C library should explicitly set errno to zero before calling a function that sets errno. Note: The macro errno cannot be used as a declarator when $CONCURRENTEXECUTION or $SHARING=SHAREDBYALL and any of the standard heads have been included. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 08:23PM +0200 Am 07.10.2021 um 10:23 schrieb David Brown: > stage it was no longer a major development line for Freescale. A > decade or so before that, ColdFire was one of the most popular > architectures in small network devices such as SOHO NAT routers, ... MIPS was dominant in routers before it was replaced with ARM. 68K had a straighter instruction-set than x86, but the two times indirect addressing-modes introduced with the 68020 were totally brain-damaged. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment