- Can extern "C" functions throw exceptions - 2 Updates
- Tricky ... - 16 Updates
- How to get mantissa of long double? - 7 Updates
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Oct 06 05:03PM -0700 > On 2021-10-06, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: [...] >> the Windows calculator program). > Who cares, this is not *mderated* group, you just embarrased yourself > not recognizing simple calculator in Haskell :P I care, and most readers here do as well. >> Consider whether it's appropriate. > It is talk was about calculator :p *PLONK* -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Oct 07 07:09AM -0700 On Wednesday, October 6, 2021 at 4:12:52 PM UTC-4, Tim Rentsch wrote: > James Kuyper <james...@alumni.caltech.edu> writes: > > On 9/12/21 9:44 AM, Chris Vine wrote: ... > Can you illustrate how that would be done? Since the language > linkage of a function is part of its type, it sounds like trying > to do such a thing would inevitably lead to undefined behavior. The language linkage of a function's type is indeed part of that type. The language linkage of a function's name is not. The standard's description of language linkage in 9.11p1 starts with the sentence "All function types, function names with external linkage, and variable names with external linkage have a language linkage.", clearly making the point that the language linkage of a function's type is a distinct thing from the language linkage of a function's name. The standard could have inextricably linked them together - but it does not. In fact, 9.11p5 includes an example demonstrating how they can be separated: extern "C" typedef void FUNC(); FUNC f2; // the name f2 has C ++ language linkage and the // function's type has C language linkage Now, the standard can and does contain example code that violates a C++ rule, as a way of explaining what that rule means. However, when it does so, it almost always includes a comment next to the offending line pointing out that it violates a rule. There's no such comment in this example. In fact, the only comments explicitly describe the well-defined meaning of that code. All quotes are from n4860.pdf, the latest draft version of the C++ language that I have access to. However, this is not a new feature of the language; it has been part of standard C++ for as long as C++ has been standardized. I'm not sure about pre-standard C++ - my copy of Stroustrup's book went missing many years ago. The C++ language linkage of f2's name means that it can be referred to by name in C++ code, but not in C code. The C language linkage of f2's type means that f2 can called from C as well as from C++. However, since the function's name can't be referred to by C code, it must be called using a pointer, and that pointer's value can only come from C++ code. It could be passed to the C part of a program as a function parameter, or returned as the value of a function call, or placed in a function pointer object shared between the C and C++ parts of a program. I don't see any reasonable use for the opposite: a function whose name has C language linkage and whose type has C++ language linkage. C has no way of correctly declaring the type of the function associated with that name, and the function's name cannot be declared without specifying it's type. Such a function would be callable by name from C++ but I don't see any particular advantage of that. I don't think that the ability to separate the language linkage of a function's type from the language linkage of the function's name was a strongly desired feature in itself. I suspect that it is simply a side-effect that arose naturally from the fact that those are two different aspects of language linkage, combined with the way typedefs work. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 06 05:19PM -0700 On 10/2/2021 1:57 AM, Bonita Montero wrote: >> The idea is to try to minimize slow-paths... Think about it! Damn >> it... ;^o > The idea of lock-free algorithms is not to have slow paths at all. Why not? You have a very narrow view. A pure lock-free fast-path is ideal. A wait-free fast-path is even better! > Otherwise they wouldn't be lock-free. Forgot about that all or nothing line of thought for a moment. Think outside of the box, so to speak... >> idiotic? Wow. > No, lock-free algortims involve polling because there is never any > kernel-waiting. And polling is out of question. ARGH! Try to pull your head out of the proverbial sand for a moment? A lock/wait-free fast-path is great! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 06 06:11PM -0700 On 10/3/2021 9:42 PM, Branimir Maksimovic wrote: >> Search for my last name in the page: >> http://www.fractalforums.com/new-theories-and-research/plotting-field-lines-during-iteration/ > Found, THANKS! No problem. Fwiw, here is a new test animation I made: https://youtu.be/nPR4xK-5i4I https://www.youtube.com/watch?v=nPR4xK-5i4I Both links work for me. How many work for you? Just wondering. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 06 06:22PM -0700 On 10/2/2021 4:07 AM, Bonita Montero wrote: >> Yes. > Or more precisely: pracitcally yes. Because other uses aren't > practicable because of the drawbacks of lock-free algorithms. think outside of the box. |
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 07 02:17AM > ideal. A wait-free fast-path is even better! Then, you have to think what to do, when there is is nothing to do :P -- 7-77-777 Evil Sinner! to weak you should be meek, and you should brainfuck stronger https://github.com/rofl0r/chaos-pp |
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 07 02:20AM > https://youtu.be/nPR4xK-5i4I > https://www.youtube.com/watch?v=nPR4xK-5i4I > Both links work for me. How many work for you? Just wondering. Watched, beautiful Thanks! -- 7-77-777 Evil Sinner! to weak you should be meek, and you should brainfuck stronger https://github.com/rofl0r/chaos-pp |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 06 07:38PM -0700 On 10/6/2021 7:17 PM, Branimir Maksimovic wrote: >> ideal. A wait-free fast-path is even better! > Then, you have to think what to do, when there is is nothing > to do :P When the fast-path fails, we can choose to try to wait. Usually on a Futex or Eventcount. The main idea is under periods of load, when the structure is not empty, we can fly along lock/wait-free paths. |
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 07 02:45AM > When the fast-path fails, we can choose to try to wait. Usually on a > Futex or Eventcount. The main idea is under periods of load, when the > structure is not empty, we can fly along lock/wait-free paths. iWhat you think about this code: while(true){ usleep(1000) /// we dpn't want to overheat :P /*** * interrestingly CAS doesn't work, because of * some weird Apple memory scheme. * OSAtomicCompareAndSwapPtr: doesn't work */ var val:UInt8 = 0 repeat { usleep(1) OSMemoryBarrier() val = bval!.pointee!.load(as:UInt8.self) }while ( val == 1 || val == 2) OSMemoryBarrier() bval!.pointee!.storeBytes(of:1,as: UInt8.self) repeat { usleep(1) OSMemoryBarrier() val = bval!.pointee!.load(as:UInt8.self) }while ( val == 2) OSMemoryBarrier() bval!.pointee!.storeBytes(of:2,as: UInt8.self) print("acquired") /// payLoad OSMemoryBarrier() bval!.pointee!.storeBytes(of:0,as: UInt8.self) print("releazed\n") -- 7-77-777 Evil Sinner! to weak you should be meek, and you should brainfuck stronger https://github.com/rofl0r/chaos-pp |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 06 08:01PM -0700 On 10/6/2021 7:45 PM, Branimir Maksimovic wrote: > OSMemoryBarrier() > bval!.pointee!.storeBytes(of:0,as: UInt8.self) > print("releazed\n") I need to really examine it, but it kind of reminds me of a way to load things up in some sort of odd sequence lock. There is a shitload of membars in there. Heck, is OSMemoryBarrier akin to a #StoreLoad | #LoadStore | #Load#Load | #Store#Store on the SPARC, in other words seq order? Humm... I cannot believe that CAS does not work! What does std::atomic<T>::compare_exchange_weak() with a membar of std::memory_order_relaxed disassemble into? Btw, a seqlock is: https://en.wikipedia.org/wiki/Seqlock If OSMemoryBarrier is seq_order this this should go really slow. |
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 07 03:24AM > order? Humm... I cannot believe that CAS does not work! What does > std::atomic<T>::compare_exchange_weak() with a membar of > std::memory_order_relaxed disassemble into? Problem is OS, how it maps memory. I didn't figured out why, but simply value is not readed, that is, if I do it in assembler, 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 -- 7-77-777 Evil Sinner! to weak you should be meek, and you should brainfuck stronger https://github.com/rofl0r/chaos-pp |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 07 08:36AM +0200 Am 06.10.2021 um 21:22 schrieb Chris M. Thomasson: >>> Why not combine the two? Ahhh, the futex, or eventcount. >> Then it's not lock-free anymore. > However, it has lock-free fast-paths. That is a huge advantage! Then you could call every mutex lock-free. But no one does that. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 07 08:37AM +0200 Am 07.10.2021 um 02:19 schrieb Chris M. Thomasson: >> The idea of lock-free algorithms is not to have slow paths at all. > Why not? You have a very narrow view. A pure lock-free fast-path is > ideal. A wait-free fast-path is even better! That's not a narrow view but it is how it's defined. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 07 12:31AM -0700 On 10/6/2021 11:36 PM, Bonita Montero wrote: >>> Then it's not lock-free anymore. >> However, it has lock-free fast-paths. That is a huge advantage! > Then you could call every mutex lock-free. But no one does that. You can call access to an unlocked mutex a fast-path. It sounds like you have never heard of a benaphore before. Too bad. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 07 01:15AM -0700 On 10/6/2021 11:37 PM, Bonita Montero wrote: >> Why not? You have a very narrow view. A pure lock-free fast-path is >> ideal. A wait-free fast-path is even better! > That's not a narrow view but it is how it's defined. Yeah... Think outside of the box and use a lock/wait-free algorihtm for a fast-path, and use a Futex or Eventcount for the slow-path. |
| Ian Collins <ian-news@hotmail.com>: Oct 07 10:26PM +1300 On 07/10/2021 14:11, Chris M. Thomasson wrote: > https://youtu.be/nPR4xK-5i4I > https://www.youtube.com/watch?v=nPR4xK-5i4I > Both links work for me. How many work for you? Just wondering. Cool! -- Ian. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 07 12:15PM +0200 Am 07.10.2021 um 09:31 schrieb Chris M. Thomasson: >>> However, it has lock-free fast-paths. That is a huge advantage! >> Then you could call every mutex lock-free. But no one does that. > You can call access to an unlocked mutex a fast-path. Yes, but because of that fast path a mutex isn't lock-free. You say that everything having a fast path could be called lock-free. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 07 12:16PM +0200 Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson: >> That's not a narrow view but it is how it's defined. > Yeah... Think outside of the box and use a lock/wait-free algorihtm > for a fast-path, and use a Futex or Eventcount for the slow-path. Lock-free algorithms don't have a slow path. That's while they don't lock and you've to poll them. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 07 05:35AM > Does anyone know if type punning through a union is still undefined > behavior? > Also, I believe bitfield allocation is implementation defined. Also, the above union assumes that the long double value is stored in the 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. And, as you say, it's not defined whether that sign bit will be the lowest or highest bit of that 16-bit bitfield. (I don't think the standard even guarantees that the 1-bit will be stored in the same bytes as the 15-bits.) You could make some compile-time checks to see that the union will have the proper internal structure (and refuse to compile otherwise), although IIRC there's no way to check endianess at compile time (unless C++20 added some new features to do that). |
| David Brown <david.brown@hesbynett.no>: Oct 07 08:17AM +0200 On 06/10/2021 18:44, red floyd wrote: >> Just store your value into value and extract the mantissa from mantissa. > Does anyone know if type punning through a union is still undefined > behavior? Yes, it is. It's not uncommon to for compilers to generate code as though it /were/ defined in C++ (it is defined behaviour in C), especially for unions of simple types. But compilers don't (IME) guarantee it. The standard method for accessing "raw" bit patterns that is always safe, is memcpy(). In C++20, there is now std::bit_cast<>, which also lets you do get type-punning effects. (And if anyone tells you type-punning unions "work" in C++, then ask why std::bit_cast<> was added to the language.) |
| David Brown <david.brown@hesbynett.no>: Oct 07 08:20AM +0200 On 07/10/2021 07:35, Juha Nieminen wrote: > the proper internal structure (and refuse to compile otherwise), although > IIRC there's no way to check endianess at compile time (unless C++20 > added some new features to do that). C++20 added std::endian for convenience and standardisation of common compiler features for endianness: <https://en.cppreference.com/w/cpp/types/endian> |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 07 08:38AM +0200 Am 07.10.2021 um 07:35 schrieb Juha Nieminen: > Also, the above union assumes that the long double value is stored in the > 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. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 07 08:38AM +0200 Am 07.10.2021 um 08:20 schrieb David Brown: > C++20 added std::endian for convenience and standardisation of common > compiler features for endianness: Why an endianess check here ? There are no big-endian machines with 80 bit FP. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 07 08:42AM +0200 Am 07.10.2021 um 08:38 schrieb Bonita Montero: >> compiler features for endianness: > Why an endianess check here ? > There are no big-endian machines with 80 bit FP. Oh, I just remembered the 68K FPUs. These have 80 bit FP. But 68K is dead today. |
| David Brown <david.brown@hesbynett.no>: Oct 07 10:23AM +0200 On 07/10/2021 08:42, Bonita Montero wrote: >> There are no big-endian machines with 80 bit FP. > Oh, I just remembered the 68K FPUs. These have 80 bit FP. > But 68K is dead today. The 68k ISA lives on in the microcontroller world, as the ColdFire processors, though I don't believe any new ColdFire microcontrollers have been released since NXP bought Freescale in 2015. Even at that 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, and was the main target for the MMU-less Linux version ucLinux. This was all long after the 68k was gone from desktops, workstations, home computers, etc. (Because ucLinux does not support fork(), this lead to an increased use of spawn() instead of fork-exec, which then made porting to Windows easier. So if you use any *nix-heritage software on your Windows machine, that may be partly thanks to the 68k architecture.) Some of the 68k-based microcontrollers are immortal. People still make devices using the renowned 68332, though it is around 30 years old. However, few of these embedded uses used floating point, and the the bigger ColdFire processors with hardware floating point support all used 64-bit floats. 80-bit floats were used in the 68882 FPU co-processor, and the 68040 and 68060 processors. The first serious electronics board I designed had a 68332 with a 68882 co-processor, many years ago. (The current version of the same system is, unsurprisingly, ARM based.) |
| 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