| woodbrian77@gmail.com: Sep 01 06:58PM -0700 On Sunday, September 1, 2019 at 2:39:57 PM UTC-5, Richard Damon wrote: > messages is generally good. Making the Error comment optional might make > some sense if the Error Condition is fully self documenting, but the > linkage between IEC559 and IEEE754 isn't inherently obvious. Right. > I might > even extend the error message to something more verbose, like > IEEE754/IEC559 Floating point assumed and needed I don't like having iec559 in there. If they want they can look at the line for more info. I agree in principle that that's a better message. On the other hand, some say this isn't likely to assert very often so the error message may not be that important. |
| Robert Wessel <robertwessel2@yahoo.com>: Sep 01 10:29PM -0500 >> support both IEEE and IBM S/360 hex style floats via a compiler >> option. In any event, numeric_limits::is_iec559 is C++11, and >I'm not sure what that last part means. It was asserted that no non-IEEE FP C++17 implementations are likely to ever exist, since such architectures largely no longer exist. I pointed out that the C++ compiler for IBM mainframes in the S/360 line, while not yet C++17, supports both the traditional S/360 hex floating point format (which is decidedly *not* IEEE FP), as well as IEEE-style FP. And that a C++17 version of that compiler is generally expected, and that it's expected that it will continue to support both FP formats. When hex FP is selected, numeric_limits::is_iec559, as expected, will be false. >static_assert(::std::numeric_limits<float>::is_iec559,"IEEE754"); >To rephrase my original question, do you use comments at >all with static_assert if you are using 2017 C++? Certainly I see little that a comment could add to the above assertion. |
| Robert Wessel <robertwessel2@yahoo.com>: Sep 01 10:34PM -0500 On Sun, 01 Sep 2019 22:29:42 -0500, Robert Wessel >>all with static_assert if you are using 2017 C++? >Certainly I see little that a comment could add to the above >assertion. OK, you meant should a *message* be used (not a comment) in the static assertion (at least in C++17, where the message is now optional). Obviously it depends on the context. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 01 08:35PM -0700 On 9/1/2019 7:21 AM, Robert Wessel wrote: > support both IEEE and IBM S/360 hex style floats via a compiler > option. In any event, numeric_limits::is_iec559 is C++11, and > supported on that compiler as you expect for both hex and binary FP. I want to see the DWCAS impl for z/OS. It should be able to handle the normal lock-free lifo: Appendix 48 : A-48 in, Free Pool Manipulation: https://www-01.ibm.com/support/docview.wss?aid=1&uid=isg26480faec85f44e2385256d5200627dee |
| Keith Thompson <kst-u@mib.org>: Sep 01 08:48PM -0700 > a. remove the comment > b. reduce the comment to just "IEEE754", or > c. leave it as it is. The issue is that in C++11 and earlier, static_assert requires a second argument (which is *not* a "comment"), and in C++17 and later it does not. Given what you have, I can't think of any good reason not to leave it as it is. If you do drop the message argument, your code will no longer compile with a pre-2017 C++. implementation (unless it supports a single-argument static_assert as an extension). If it won't anyway for other reasons, that probably doesn't matter. What advantage do you see from removing or changing the message argument? -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| Robert Wessel <robertwessel2@yahoo.com>: Sep 01 10:50PM -0500 On Sun, 1 Sep 2019 20:35:27 -0700, "Chris M. Thomasson" >normal lock-free lifo: >Appendix 48 : A-48 in, Free Pool Manipulation: >https://www-01.ibm.com/support/docview.wss?aid=1&uid=isg26480faec85f44e2385256d5200627dee You need to find a newer PoOp. That one is 15 years out of date. Search for "SA22-7832-11". I'm also not quite sure what you're asking. The ISA implements CAS and DWCAS (CSxx and CDxx instructions) as well as some other compare-and-swap variations in both 32 and 64-bit sizes. A number of additional atomic operations exist under the Perform Locked Operation instruction. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 01 09:12PM -0700 On 9/1/2019 8:50 PM, Robert Wessel wrote: > compare-and-swap variations in both 32 and 64-bit sizes. A number of > additional atomic operations exist under the Perform Locked Operation > instruction. Right. So C++11 on the zArch can support 64-bit double width compare-and-swap atomics with 32 bit words. And 128 DWCAS with 64 bit words, right? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 01 09:13PM -0700 On 9/1/2019 8:50 PM, Robert Wessel wrote: >> https://www-01.ibm.com/support/docview.wss?aid=1&uid=isg26480faec85f44e2385256d5200627dee > You need to find a newer PoOp. That one is 15 years out of date. > Search for "SA22-7832-11". Afaict, this is still there in appendix A on the most recent version. |
| Robert Wessel <robertwessel2@yahoo.com>: Sep 02 12:09AM -0500 On Sun, 1 Sep 2019 21:12:08 -0700, "Chris M. Thomasson" >Right. So C++11 on the zArch can support 64-bit double width >compare-and-swap atomics with 32 bit words. And 128 DWCAS with 64 bit >words, right? Yes. CDSG does a compare and swap on a 128-bit value stored in a pair of (64-bit) registers with a quadword in memory. Compare and Swap and Store is something of enhancement, and allows for the miscompared value to update another structure in the same atomic operation. Perform Locked Operation can do a variety of atomic operation including DCAS, and CAS with multiple updates. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 02 07:14AM +0200 > I want to see the DWCAS impl for z/OS. > ... Why? Do you have bought such a system? |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 02 07:16AM +0200 >>> to add some bulk to his website that promotes misogyny and homophobia. >> Maybe, but your style of response isn't mature. > Neither is deliberately snipping attributions... You're right. I will go to the psychotherapist because of that !!!!!!!!! |
| Robert Wessel <robertwessel2@yahoo.com>: Sep 02 12:20AM -0500 On Sun, 1 Sep 2019 21:13:02 -0700, "Chris M. Thomasson" >> You need to find a newer PoOp. That one is 15 years out of date. >> Search for "SA22-7832-11". >Afaict, this is still there in appendix A on the most recent version. It is, although that's not saying much - a non-trivial portion of the content of Appendix A has been only minimally changed since 1964. Although not the examples for CS/CDS, those only date back to S/370. See page 122 of: http://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 01 10:39PM -0700 On 9/1/2019 10:09 PM, Robert Wessel wrote: > operation. > Perform Locked Operation can do a variety of atomic operation > including DCAS, and CAS with multiple updates. Ohhh, yeah. The PLO instruction is very interesting indeed! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 01 10:41PM -0700 On 9/1/2019 10:20 PM, Robert Wessel wrote: > It is, although that's not saying much - a non-trivial portion of the > content of Appendix A has been only minimally changed since 1964. > Although not the examples for CS/CDS, those only date back to S/370. The lock-free lifo is there to stay. > See page 122 of: > http://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf Will do. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 01 10:46PM -0700 On 9/1/2019 10:14 PM, Bonita Montero wrote: >> I want to see the DWCAS impl for z/OS. >> ... > Why? Do you have bought such a system? No. Just want to see the generated asm. Lock-Free and Appendix A have been around for a long time. Btw, did you know that CAS is actually the initials for the person who invented it? |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 02 07:55AM +0200 > No. Just want to see the generated asm. Lock-Free > and Appendix A have been around for a long time. Those systems aren't really relevant because they're sold in homeopathic amounts. > A have been around for a long time. Btw, did you know that > CAS is actually the initials for the person who invented it? Thiy might be a myth. I can only get a single Stack Overflow reference on that where only his first name is remembered. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 01 10:58PM -0700 On 9/1/2019 10:55 PM, Bonita Montero wrote: >> CAS is actually the initials for the person who invented it? > Thiy might be a myth. I can only get a single Stack Overflow > reference on that where only his first name is remembered. Stack Overflow wrt a Lock-Free Lifo? How did you manage to get that? Ohhh... The C in CAS stands for Charlie. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 01 10:58PM -0700 On 9/1/2019 10:55 PM, Bonita Montero wrote: >> CAS is actually the initials for the person who invented it? > Thiy might be a myth. I can only get a single Stack Overflow > reference on that where only his first name is remembered. Myth!? No. Its real. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 01 10:59PM -0700 On 9/1/2019 10:58 PM, Chris M. Thomasson wrote: >> Thiy might be a myth. I can only get a single Stack Overflow >> reference on that where only his first name is remembered. > Myth!? No. Its real. Ask over on comp.arch... The CAS is the initials of the person who invented it. IBM! |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 02 08:20AM +0200 >> Thiy might be a myth. I can only get a single Stack Overflow >> reference on that where only his first name is remembered. > Stack Overflow wrt a Lock-Free Lifo? How did you manage to get that? https://bit.ly/2kinTqE > Ohhh... The C in CAS stands for Charlie. As soon as I can find his full name with fits so C.A.S. and I can find something referencing him as a researcher or whatever I don't belive this. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 01 11:24PM -0700 On 9/1/2019 11:20 PM, Bonita Montero wrote: > As soon as I can find his full name with fits so C.A.S. > and I can find something referencing him as a researcher > or whatever I don't belive this. Ask over on comp.arch. You might be lucky enough to talk to another IBM guy that knew him. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 01 11:25PM -0700 On 9/1/2019 11:24 PM, Chris M. Thomasson wrote: >> or whatever I don't belive this. > Ask over on comp.arch. You might be lucky enough to talk to another > IBM guy that knew him. Think of Anne & Lynn Wheeler.... ;^) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 01 11:26PM -0700 On 9/1/2019 11:25 PM, Chris M. Thomasson wrote: >> Ask over on comp.arch. You might be lucky enough to talk to another >> IBM guy that knew him. > Think of Anne & Lynn Wheeler.... ;^) read all... https://groups.google.com/forum/?hl=en#!original/comp.arch/JkcTGC9X3lo/M4Vo_cXKEwAJ Still, create a new post over on comp.arch |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 02 06:47AM +0200 > If the result of not handling the error in time is someone gets killed, > maybe it is. We're not discussing about error handling or not; wer're discussing the performance-impacts. > sometimes real WORSE case performance is, sometimes the error path may > have relaxed requirements, but sometimes it still has definite > requirements. You don't have any clue what you're talking about. You simply fantasizing to emphasize your authority. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 02 07:20AM +0200 Sorry, I had a background task that was encoding a video through x265. I thought that it is simply sufficient to put it on idle -priority. But the issue I hadn't in mind was that this task is stealing "cycles" on the the other thread of a core. Without any competing cycles on that core the time to throw and catch an exception is only about 8.600 cycles on my Ryzen 7 1800X. But I'm still curious about the performance of other implementa- tions. |
| 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