Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #4065 > unrolled thread
| Started by | "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> |
|---|---|
| First post | 2011-10-08 02:54 +0200 |
| Last post | 2011-10-13 12:10 +0200 |
| Articles | 20 on this page of 89 — 21 participants |
Back to article view | Back to comp.arch
Infinity + Infinity (or NegInfinity - NegInfinity) "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-10-08 02:54 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Robert Myers <rbmyersusa@gmail.com> - 2011-10-07 18:40 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) James Kuyper <jameskuyper@verizon.net> - 2011-10-07 22:39 -0400
Re: Infinity + Infinity (or NegInfinity - NegInfinity) William Elliot <marsh@rdrop.com> - 2011-10-07 19:56 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Jasen Betts <jasen@xnet.co.nz> - 2011-10-08 06:45 +0000
Re: Infinity + Infinity (or NegInfinity - NegInfinity) gordonb.eug6r@burditt.org (Gordon Burditt) - 2011-10-08 02:37 -0500
Re: Infinity + Infinity (or NegInfinity - NegInfinity) William Elliot <marsh@rdrop.com> - 2011-10-08 21:40 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Kaba <kaba@nowhere.com> - 2011-10-09 12:17 +0300
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Jasen Betts <jasen@xnet.co.nz> - 2011-10-08 06:33 +0000
Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-10-08 16:41 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) kenney@cix.compulink.co.uk - 2011-10-09 04:01 -0500
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Kaba <kaba@nowhere.com> - 2011-10-08 17:43 +0300
Re: Infinity + Infinity (or NegInfinity - NegInfinity) "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-10-08 10:20 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Kaba <kaba@nowhere.com> - 2011-10-08 22:35 +0300
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-08 18:55 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Kaba <kaba@nowhere.com> - 2011-10-08 23:03 +0300
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-08 21:27 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) James Kuyper <jameskuyper@verizon.net> - 2011-10-08 17:28 -0400
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Robert Myers <rbmyersusa@gmail.com> - 2011-10-08 18:15 -0400
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-08 23:23 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) James Kuyper <jameskuyper@verizon.net> - 2011-10-08 21:29 -0400
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-09 10:01 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Al Grant <algrant@myrealbox.com> - 2011-10-12 06:14 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-12 15:25 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) James Kuyper <jameskuyper@verizon.net> - 2011-10-12 12:10 -0400
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-12 18:41 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) James Kuyper <jameskuyper@verizon.net> - 2011-10-12 15:32 -0400
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-12 20:44 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Robert Myers <rbmyersusa@gmail.com> - 2011-10-12 18:11 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Andrew Reilly <areilly---@bigpond.net.au> - 2011-10-13 03:48 +0000
Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-12 23:15 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-13 09:12 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-13 00:49 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-13 10:37 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-13 11:04 -0400
Re: Infinity + Infinity (or NegInfinity - NegInfinity) EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-13 17:15 -0400
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-14 09:22 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-14 13:37 -0400
Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-13 11:11 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Al Grant <algrant@myrealbox.com> - 2011-10-14 01:04 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-13 09:07 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Al Grant <algrant@myrealbox.com> - 2011-10-13 07:00 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Robert Myers <rbmyersusa@gmail.com> - 2011-10-14 10:54 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Andrew Reilly <areilly---@bigpond.net.au> - 2011-10-14 22:36 +0000
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-15 09:26 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-15 05:39 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-15 14:56 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-17 08:37 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-17 12:03 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-17 11:13 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-17 22:30 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-17 14:47 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-18 11:33 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-18 10:21 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-18 08:16 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-18 14:26 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-18 13:32 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-18 17:47 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-18 17:51 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-19 10:37 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-19 09:36 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-19 11:46 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-19 10:45 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-19 13:11 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-19 12:12 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-19 16:22 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-19 15:16 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Andrew Reilly <areilly---@bigpond.net.au> - 2011-10-15 20:16 +0000
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Robert Myers <rbmyersusa@gmail.com> - 2011-10-15 16:26 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-17 08:14 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-17 08:22 +0100
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-17 11:39 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) rpw3@rpw3.org (Rob Warnock) - 2011-10-17 21:00 -0500
Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-10-18 05:44 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-17 21:35 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Jasen Betts <jasen@xnet.co.nz> - 2011-10-24 02:40 +0000
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-27 00:32 +0300
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-27 10:41 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-27 13:10 +0300
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-27 13:53 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Keith Thompson <kst-u@mib.org> - 2011-10-12 12:34 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Al Grant <algrant@myrealbox.com> - 2011-10-13 06:39 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) James Kuyper <jameskuyper@verizon.net> - 2011-10-13 10:34 -0400
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Al Grant <algrant@myrealbox.com> - 2011-10-14 00:54 -0700
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Larry Hewitt <larryhwtt@comporium.net> - 2011-10-09 21:35 -0400
Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-10-10 04:37 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Larry Hewitt <larryhwtt@comporium.net> - 2011-10-10 13:58 -0400
Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-10-13 20:17 +0200
Re: Infinity + Infinity (or NegInfinity - NegInfinity) Arivald <arivald_@AT_interia_DOT_.pl> - 2011-10-13 12:10 +0200
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-10-08 21:29 -0400 |
| Message-ID | <j6qte6$pd$1@dont-email.me> |
| In reply to | #4099 |
On 10/08/2011 06:23 PM, nmm1@cam.ac.uk wrote: > In article <j6qf8u$hji$1@dont-email.me>, > James Kuyper <jameskuyper@verizon.net> wrote: >> ... >>> The IEEE 754 model is incompatible with most language's arithmetic >>> models, >> >> That claim would be more useful if you would at least hint at what the >> typical incompatibilities are. I doubt that the writers of that standard >> intended it to be incompatible with those languages, and I doubt that >> the designers of all of those languages went out of their way to be >> incompatible with that standard, which suggests that any such >> incompatibility is likely to be subtle. If so, reading the IEEE 754 >> standard and comparing it with the language standards is not likely to >> be fruitful without at least a hint of what incompatibilities to look for. > > Aargh! You have got the whole thing arsey-versey. If there isn't > any match between the basic concepts, what on earth is the point > in looking for detailed incompatibilities? I said that the MODELS > were incompatible and not that the DETAILS were. Then please explain the incompatibility you see in the models. Are the problematic features of the IEEE 754 standard shared by the IEEE 854? I've got a copy of that standard, and am somewhat familiar with it (I wouldn't claim to be an expert, by any means). I do consider myself a fair expert on the C99 standard, and I haven't noticed any incompatibilities of the very fundamental nature that you're implying. Your citation from the Fortran standard didn't do anything to clarify the issue for me. I'm not saying you're wrong. As it stands, I have no idea what you're talking about, so I can't judge whether or not you're right. If you have any inclination to be less cryptic, please let me know. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-09 10:01 +0100 |
| Message-ID | <j6rnsc$km1$1@gosset.csi.cam.ac.uk> |
| In reply to | #4101 |
In article <j6qte6$pd$1@dont-email.me>, James Kuyper <jameskuyper@verizon.net> wrote: > >Then please explain the incompatibility you see in the models. Are the >problematic features of the IEEE 754 standard shared by the IEEE 854? Yes. >I've got a copy of that standard, and am somewhat familiar with it (I >wouldn't claim to be an expert, by any means). I do consider myself a >fair expert on the C99 standard, and I haven't noticed any >incompatibilities of the very fundamental nature that you're implying. >Your citation from the Fortran standard didn't do anything to clarify >the issue for me. > >I'm not saying you're wrong. As it stands, I have no idea what you're >talking about, so I can't judge whether or not you're right. If you have >any inclination to be less cryptic, please let me know. Sorry - things have been a little stressful. IEEE 754 is based on a serial assembler model, where arithmetic is a sequence of basic operations. And both aspects are critical. Fortran is based on an evaluation of mathematical expressions, and is not in terms of basic operations, nor even necessarily serial. There just isn't any match between the models. Most languages are like Fortran, though usually less explicit, and with less implied freedom for the implementor. If I recall from my time on WG2, Pascal is one such. Python definitely is. I can't remember about Ada, but I vaguely recall it being, too. As are most of the other hundreds of languages I have looked at in my time. The original intent of WG14 was similar (I was involved - remember the unary plus proposal?) and the standards was deliberately left ambiguous (NOT my choice). Later revisionists claimed that C had always specified the execution order implied by one reading of the syntax, but that is completely false, and is contradicted by other wording, anyway (try 6.5#3, for a start). As I said, I am NOT going to go into the complete mess that is FLT_EVAL_METHOD, the pragmas, Annex F and all that - I tried to get some sanity injected during C99's standardisation, and failed, which is the main reason I voted against it. C++ is similar, but different. I raised this there and WG21 kicked it into the long grass. As I understand it, the intent is that the order is unconstrained, but serial execution is assumed. For Java, see Kahan's paper. Its value semantics match; its flag ones don't. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Al Grant <algrant@myrealbox.com> |
|---|---|
| Date | 2011-10-12 06:14 -0700 |
| Message-ID | <88cbbc8b-1fab-4dde-96b0-4dd0cd7c183d@b6g2000vbz.googlegroups.com> |
| In reply to | #4113 |
On Oct 9, 10:01 am, n...@cam.ac.uk wrote: > The original intent of WG14 was similar (I was involved - remember > the unary plus proposal?) and the standards was deliberately left > ambiguous (NOT my choice). Later revisionists claimed that C had > always specified the execution order implied by one reading of the > syntax, but that is completely false, and is contradicted by other > wording, anyway (try 6.5#3, for a start). So in what respect is that incompatible with IEEE 754? C specifies not only that in (a+b)+c, a+b happens first, but that in a+b+c, a+b happens first, so it's more prescriptive than Fortran. It says things are otherwise unsequenced, but how can IEEE 754 require more than that? If IEEE 754 required a total order on all floating-point operations in a program it would have been unimplementable on any SIMD computer from ILLIAC IV onwards. C _allows_ implementations that are incompatible with IEEE 754 (e.g. ones that use a different format, or flush denormals to zero) but that's a long way from _being_ incompatible with IEEE 754.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-12 15:25 +0100 |
| Message-ID | <j74805$d1b$1@gosset.csi.cam.ac.uk> |
| In reply to | #4154 |
In article <88cbbc8b-1fab-4dde-96b0-4dd0cd7c183d@b6g2000vbz.googlegroups.com>, Al Grant <algrant@myrealbox.com> wrote: > >> The original intent of WG14 was similar (I was involved - remember >> the unary plus proposal?) and the standards was deliberately left >> ambiguous (NOT my choice). =A0Later revisionists claimed that C had >> always specified the execution order implied by one reading of the >> syntax, but that is completely false, and is contradicted by other >> wording, anyway (try 6.5#3, for a start). > >So in what respect is that incompatible with IEEE 754? C specifies >not only that in (a+b)+c, a+b happens first, but that in a+b+c, >a+b happens first, so it's more prescriptive than Fortran. You are clearly a revisionist, as well as being unfamiliar with the ISO/ANSI C standards and their implementations! There is no such statement in the C standard, and I can tell you (from personal recollection) that requiring it was NOT WG14's intent during the standardisation of C90. The BNF was intended to specify ONLY the precedence of operators and NOT the evaluation order; that was specified by the side-effect rules. If you had looked up the section of the standard I pointed you to, you would have seen both that the word used is "grouping", which is clearly intended to distinguish it from execution order, and a clear statement that the order of evaluation is unspecified. And THAT was the intent of WG14 during the standardisation of C90. I am fully aware that a lot of people are now claiming that the BNF has always been meant to define the execution order, but that flatly contradicts large chunks of other wording (especially the side-effect rules). Whether it is now what compilers do, I don't know (and don't much care, either). Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-10-12 12:10 -0400 |
| Message-ID | <4E95BBEE.3000005@verizon.net> |
| In reply to | #4155 |
On 10/12/2011 10:25 AM, nmm1@cam.ac.uk wrote: ... > There is no such statement in the C standard, and I can tell you > (from personal recollection) that requiring it was NOT WG14's intent > during the standardisation of C90. The BNF was intended to specify > ONLY the precedence of operators and NOT the evaluation order; that > was specified by the side-effect rules. > > If you had looked up the section of the standard I pointed you to, > you would have seen both that the word used is "grouping", which > is clearly intended to distinguish it from execution order, and a > clear statement that the order of evaluation is unspecified. And > THAT was the intent of WG14 during the standardisation of C90. > > I am fully aware that a lot of people are now claiming that the > BNF has always been meant to define the execution order, but that > flatly contradicts large chunks of other wording (especially the > side-effect rules). Whether it is now what compilers do, I don't > know (and don't much care, either). The freedom of C implementations to rearrange the order of evaluation is great, but it's not completely unconstrained. While there are people who have misinterpreted the BNF as fully specifying the execution order, I don't consider that to be a common position among those most familiar with the standard. A more common position, and IMO fully defensible, is that the BNF implies constraints on the execution order. For instance, in ((a+b) + (c+d)), the a+b can be executed before or after the (c+d), but both must be executed before the final addition can be performed, because that addition requires the results of those execution. The standard does not say anything explicitly about that fact, because it doesn't need to - it's implicit in what the standard does explicitly say about the dependency of the final value on the values of the sub-expressions. I've seen claims, (possibly from you?), that it's possible for a conforming implementation to generate code for a+b+c which calculates the result of a+b after (sic!) the result of that very calculation has already been added to c. However, when I asked for details of how that was supposed to work, I learned that the supposedly-conforming code calculated a+b twice - once for adding to c, and the second time for the sole purpose (as far as I could tell) of "proving" that it's permissible to compute it afterward. I'll concede that the as-if rule allows spurious extra computations to be inserted at any time, so long as they don't affect the final result. However, for an implementation that pre-#defines __STDC_IEC_559__, it seems to me that the "final result" necessarily includes the values of testable floating point environment flags; at least, if it occurs within code that actual performs such tests. You know this, but for the benefit of those who don't: C99 added <fenv.h>, providing portable C support for such flags. I remember a long discussion we had (partly off-line) in which you claimed that C99's provision of such support, in that form, made the situation worse than it would have been without it. You presented a very real list of weaknesses in the specifications, primarily consisting of things that are optional which, if I understood your arguments, could only be considered useful if mandatory. It seems to me that if a feature is optional, but I have a portable way of testing whether it's supported, and a portable way of making use of it if it is supported, that's unambiguously more useful than having nothing portably specified about that feature - I never understood your claims to the contrary.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-12 18:41 +0100 |
| Message-ID | <j74jh0$dva$1@gosset.csi.cam.ac.uk> |
| In reply to | #4156 |
In article <4E95BBEE.3000005@verizon.net>,
James Kuyper <jameskuyper@verizon.net> wrote:
>
>The freedom of C implementations to rearrange the order of evaluation is
>great, but it's not completely unconstrained.
>While there are people who have misinterpreted the BNF as fully
>specifying the execution order, I don't consider that to be a common
>position among those most familiar with the standard.
Nor do I.
> A more common
>position, and IMO fully defensible, is that the BNF implies constraints
>on the execution order. For instance, in ((a+b) + (c+d)), the a+b can be
>executed before or after the (c+d), but both must be executed before the
>final addition can be performed, because that addition requires the
>results of those execution.
Well, yes, but I never said it wasn't! What I said was that there
were lots of OTHER interpretations, which were ALSO defensible.
> The standard does not say anything
>explicitly about that fact, because it doesn't need to - it's implicit
>in what the standard does explicitly say about the dependency of the
>final value on the values of the sub-expressions.
Unfortunately, it then contradicts that in all of its statements
about side-effect ordering, and there is nothing in the standard
that distinguishes the evaluation of an assignment operator from
the evaluation of any other operator!
I could respond to the rest of your points in detail, but I am
afraid that I don't have the time, so will select just one.
>However, for an implementation that pre-#defines __STDC_IEC_559__, it
>seems to me that the "final result" necessarily includes the values of
>testable floating point environment flags; at least, if it occurs within
>code that actual performs such tests.
I can tell you that most of the proponents of that agree with you;
unfortunately a lot of WG14 didn't, and so it was left up in the air.
>You know this, but for the benefit of those who don't: C99 added
><fenv.h>, providing portable C support for such flags.
I know damn well it didn't!
Firstly, any ambiguous specification does NOT enable portability,
because the programmer assumes one thing and the implementor another.
In my experience, that is the cause of something like 85% of the
nasty bugs in C code written by experienced programmers!
Secondly, the problem is NOT solely optionality (as you claimed
that I showed) - it's serious ambiguity and even inconsistency.
Here is one example of the problem.
5.1.2.3 Program execution footnote 11:
... Floating-point operations implicitly set the status flags; ....
Implementations that support such floating-point state are required
to regard changes to it as side effects ....
6.5 Expressions para. 5:
If an exceptional condition occurs during the evaluation of an
expression (that is, if the result is not mathematically defined or
not in the range of representable values for its type), the behavior
is undefined.
7.6 Floating-point environment para. 1:
... A floating-point status flag is a system variable whose value
is set (but never cleared) when a floating-point exception is
raised, which occurs as a side effect of exceptional floating-point
arithmetic to provide auxiliary information. ...
Now, 6.5 states unequivocally that exceptional conditions lead to
undefined behaviour, which is assuredly sometimes the case. But
Annex F states they are not if __STDC_IEC_559__ is defined. Why
do you claim that the latter overrides the former, and not the
former the latter?
That would have been trivial to fix, but there are a zillion other
such inconsistencies, all of which give scope to implementors to
do something that the programmer doesn't expect, and where the
implementation can still claim to be conforming. That's NOT a
recipe for portability!
Regards,
Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-10-12 15:32 -0400 |
| Message-ID | <4E95EB4F.20903@verizon.net> |
| In reply to | #4159 |
On 10/12/2011 01:41 PM, nmm1@cam.ac.uk wrote: > In article <4E95BBEE.3000005@verizon.net>, > James Kuyper <jameskuyper@verizon.net> wrote: ... >> position, and IMO fully defensible, is that the BNF implies constraints >> on the execution order. For instance, in ((a+b) + (c+d)), the a+b can be >> executed before or after the (c+d), but both must be executed before the >> final addition can be performed, because that addition requires the >> results of those execution. > > Well, yes, but I never said it wasn't! What I said was that there > were lots of OTHER interpretations, which were ALSO defensible. I'm sure that there are alternative interpretations, many of them defensible. The relevant thing would be a defensible interpretation that differs from the one I gave in ways that would be problematic. Every problematic interpretation I could come up with was indefensible for reasons directly connected to the fact that was problematic. Could you give an example? ... >> However, for an implementation that pre-#defines __STDC_IEC_559__, it >> seems to me that the "final result" necessarily includes the values of >> testable floating point environment flags; at least, if it occurs within >> code that actual performs such tests. > > I can tell you that most of the proponents of that agree with you; > unfortunately a lot of WG14 didn't, and so it was left up in the air. An argument against that interpretation would be more relevant than an assertion that there are people who believe in the validity of that argument. >> You know this, but for the benefit of those who don't: C99 added >> <fenv.h>, providing portable C support for such flags. > > I know damn well it didn't! It might not have done it as well as you might have liked - but it did do it. :-) ... > Secondly, the problem is NOT solely optionality (as you claimed > that I showed) ... That's the main thing I remembered you arguing; I didn't mean to imply that the arguments I remembered were the only ones you actually made - my memory's not that good. > ... - it's serious ambiguity and even inconsistency. > Here is one example of the problem. > > 5.1.2.3 Program execution footnote 11: > > ... Floating-point operations implicitly set the status flags; .... > Implementations that support such floating-point state are required > to regard changes to it as side effects .... > > 6.5 Expressions para. 5: > > If an exceptional condition occurs during the evaluation of an > expression (that is, if the result is not mathematically defined or > not in the range of representable values for its type), the behavior > is undefined. > > 7.6 Floating-point environment para. 1: > > ... A floating-point status flag is a system variable whose value > is set (but never cleared) when a floating-point exception is > raised, which occurs as a side effect of exceptional floating-point > arithmetic to provide auxiliary information. ... > > Now, 6.5 states unequivocally that exceptional conditions lead to > undefined behaviour, which is assuredly sometimes the case. But > Annex F states they are not if __STDC_IEC_559__ is defined. Why > do you claim that the latter overrides the former, and not the > former the latter? Specifications for particular cases are routinely considered to override any conflicting specification covering more the general cases; the standard would require a lot of complicated re-wording if that weren't true. #ifdef __STDC_IEC_559__ is more specific than #ifndef. > That would have been trivial to fix, What fix do you think would be needed? "An implementation that defines __STDC_IEC_559_ _ shall conform to the specifications in this annex." (F1.1). Should they add the words "even in circumstances where the rest of the standard says that the behavior is undefined."? That would seem redundant with the simple word "shall" to me. What does the "shall" mean in this context if it doesn't already imply that? 4p1: "‘‘shall’’ is to be interpreted as a requirement on an implementation or on a program;" This is clearly a requirement imposed on the implementation. 3.4.3p1: undefined behavior "behavior, ... for which this International Standard imposes no requirements." Annex F is a part of "this International Standard", is labeled as normative, and imposes requirements for the behavior when an implementation chooses to pre-#define __STDC_IEC_559__. That doesn't seem to meet the standard's definition of "undefined behavior".
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-12 20:44 +0100 |
| Message-ID | <j74qml$el1$1@gosset.csi.cam.ac.uk> |
| In reply to | #4161 |
In article <4E95EB4F.20903@verizon.net>, James Kuyper <jameskuyper@verizon.net> wrote: > >>> position, and IMO fully defensible, is that the BNF implies constraints >>> on the execution order. For instance, in ((a+b) + (c+d)), the a+b can be >>> executed before or after the (c+d), but both must be executed before the >>> final addition can be performed, because that addition requires the >>> results of those execution. >> >> Well, yes, but I never said it wasn't! What I said was that there >> were lots of OTHER interpretations, which were ALSO defensible. > >I'm sure that there are alternative interpretations, many of them >defensible. The relevant thing would be a defensible interpretation that >differs from the one I gave in ways that would be problematic. Every >problematic interpretation I could come up with was indefensible for >reasons directly connected to the fact that was problematic. Could you >give an example? Dammit, you have JUST seen TWO!!! One is that the BNF defines the execution order, except where explicitly varied. The other is that the grouping defines only the operator precedence and not how the expression is evaluated. AS I SAID, I was active in WG14 at the time, and I understood that to be the nearest it got to a consensus. >>> You know this, but for the benefit of those who don't: C99 added >>> <fenv.h>, providing portable C support for such flags. >> >> I know damn well it didn't! > >It might not have done it as well as you might have liked - but it did >do it. :-) No, it didn't, BECAUSE IT'S NOT PORTABLE. That isn't just theory, but the experience of being in WG14, interaction with vendors and actually running tests. >Specifications for particular cases are routinely considered to override >any conflicting specification covering more the general cases; the >standard would require a lot of complicated re-wording if that weren't >true. #ifdef __STDC_IEC_559__ is more specific than #ifndef. Well, that's NOT how they have been normally interpreted on the WG14 mailing list - I don't have the time to try to remember specific examples now. It IS the case for implicit undefined behaviour, but this is EXPLICIT. >> That would have been trivial to fix, > >What fix do you think would be needed? >"An implementation that defines __STDC_IEC_559_ _ shall conform to the >specifications in this annex." (F1.1). Should they add the words "even >in circumstances where the rest of the standard says that the behavior >is undefined."? That would seem redundant with the simple word "shall" >to me. What does the "shall" mean in this context if it doesn't already >imply that? Please do think beyond black and white. Does it apply when pragma FENV_ACCESS is not set and, if so, exactly how? Yes, there is an 'obvious' best choice there. What does it mean together with FP_CONTRACT or CX_LIMITED_RANGE on? I can tell you that the BSI never got an answer out of WG14 on that one! Does it apply to the large amount of the C language and library NOT mentioned in Annex F and, if so, exactly how? Under what conditions does it apply if any function from an external library is linked in? And, if you think there is a simple answer to that, I recommend a year or two in an ISO standards committee. Anyway, I don't have time for more. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Robert Myers <rbmyersusa@gmail.com> |
|---|---|
| Date | 2011-10-12 18:11 -0700 |
| Message-ID | <ac3cbd3b-a4a3-4d15-9fe8-e844a482849e@db5g2000vbb.googlegroups.com> |
| In reply to | #4163 |
On Oct 12, 3:44 pm, n...@cam.ac.uk wrote: > > No, it didn't, BECAUSE IT'S NOT PORTABLE. You scare me, Nick. That's only fair, because, to the extent that you pay attention to anything I say, I probably scare you. What you are really saying is that, in a code where mysterious and unreliable things are happening, you can't blindly transfer the code from one ad hoc hardware and software standard to another. Listen very carefully: THAT'S A GOOD THING. It may be the last thing standing between us and careerists who don't have a clue "validating" their results by transferring a meaningless calculation from one machine to another with no clue that something totally crazy is going on. The idea that the universe would be a safer place if only people would listen to you doesn't even pass the laugh test. Robert.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Reilly <areilly---@bigpond.net.au> |
|---|---|
| Date | 2011-10-13 03:48 +0000 |
| Message-ID | <9fn5cjFsr4U1@mid.individual.net> |
| In reply to | #4164 |
On Wed, 12 Oct 2011 18:11:12 -0700, Robert Myers wrote: > It may be the last thing standing between us and careerists who don't > have a clue "validating" their results by transferring a meaningless > calculation from one machine to another with no clue that something > totally crazy is going on. Nick does have a good point though, notwithstanding the last couple of posts in which the authors asserted that C (at least) now *does* specify a total order of operations within expressions (even ones that appear ambiguous because of expectations of associativity). I didn't realize that, and I'm still not sure that I believe them. Nick's point (I believe) is that floating point arithmetic is fraught, because it is fairly fundamentally unlike the mathematics that expression- based languages appear to be offering. In maths and exact computer arithmetic (eg integer), addition is associative and a bunch of other nice rules for "simplification" apply. In floating point they don't, because every floating point multiply (a * b), for example, is really something like round(_g_current_FPU_rounding_mode, multiply(a,b)), and every addition or subtraction is even more complicated, with a bunch of normalizations thrown in for good measure. Round is, naturally, a lossy operation. Throw in exceptions that can be raised in a bunch of ways and you wind up with something that can only really be reasoned about as a discrete sequence of assembly-language-like operations that both produce results and mutate and depend on the "system state" in obscure and platform-dependent ways. I haven't even mentioned an IEEE standard here: it ought to be possible to define a stateless floating point method, where rounding modes were explicit in the instructions and exceptions were either defined away as in-band values or made of precice exceptions, but I've never heard of it being done. Clearly you can still have parallelism between independent operations, but you can't manipulate floating point expressions that look like maths as though they were maths, at least not without giving up being able to reason about the answer. Which I think just emphasises your point, too: people doing floating point need to have a clue... Cheers, -- Andrew
[toc] | [prev] | [next] | [standalone]
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2011-10-12 23:15 -0700 |
| Message-ID | <915bd9f1-ccd2-4061-a33e-115e1ea2509e@v11g2000vbm.googlegroups.com> |
| In reply to | #4165 |
[Newsgroups trimmed] On Oct 12, 10:48 pm, Andrew Reilly <areilly...@bigpond.net.au> wrote: [snip] > Nick's point (I believe) is that floating point arithmetic is fraught, > because it is fairly fundamentally unlike the mathematics that expression- > based languages appear to be offering. In maths and exact computer > arithmetic (eg integer), addition is associative and a bunch of other > nice rules for "simplification" apply. Unless the environment provides promotion to larger precision, integer arithmetic cannot be reordered arbitrarily. E.g., d = a + b + c could overflow in one evaluation order but not in another ordering. > In floating point they don't, [snip] > > Clearly you can still have parallelism between independent operations, > but you can't manipulate floating point expressions that look like maths > as though they were maths, at least not without giving up being able to > reason about the answer. > > Which I think just emphasises your point, too: people doing floating > point need to have a clue... Unfortunately, it seems that the popular programming languages do not provide a means to express the permissibility of optimizations (not only evaluation ordering but also things like replacing division by multiplication by reciprocal [e.g., if the divisor is not changed within a loop--and this can be further complicated if the machine supports extended precision--from what I have read, IEEE 754 requires exact rounding which complicates division based on a reciprocal estimate with relatively limited benefit in numeric stability, with the same applying to square root]). From Nick's comments, it seems that the programmer must not only be familiar with numerical analysis, the target processor, and the implementation language but also with how the specific version of a compiler interprets and implements the language definition; and even then the desired semantic might not be expressible. (On a barely related side note, I would like for a language to provide function overloading to allow one definition of the function to maximize clarity for the human while providing other definitions which provide implementation hints or directives. With appropriately expressed constraints in the primary definition, the compiler might be able to validate the equivalence of the optimized definitions and the primary definition. I imagine that such could also be a suitable interface to express target-specific optimizations in a more friendly manner than conditional compilation based on #if def. The same might also apply to structure layout; a primary definition could provide semantic clarity while overloadable definitions could provide implementation hints or directives.) Paul A. Clayton just a technophile, not even a programmer
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-13 09:12 +0200 |
| Message-ID | <gkfim8-bf22.ln1@ntp6.tmsw.no> |
| In reply to | #4167 |
Paul A. Clayton wrote: > [Newsgroups trimmed] > On Oct 12, 10:48 pm, Andrew Reilly<areilly...@bigpond.net.au> wrote: >> based languages appear to be offering. In maths and exact computer >> arithmetic (eg integer), addition is associative and a bunch of other >> nice rules for "simplification" apply. > > Unless the environment provides promotion to larger precision, > integer arithmetic cannot be reordered arbitrarily. E.g., d = a + b + > c > could overflow in one evaluation order but not in another ordering. With the current integer situation, (2's complement, no overflow exceptions or even detection), any overflows don't matter: The result is still the same independent of evaluation order. > Unfortunately, it seems that the popular programming languages do > not provide a means to express the permissibility of optimizations > (not only evaluation ordering but also things like replacing division > by multiplication by reciprocal [e.g., if the divisor is not changed > within a loop--and this can be further complicated if the machine > supports extended precision--from what I have read, IEEE 754 > requires exact rounding which complicates division based on a > reciprocal estimate with relatively limited benefit in numeric > stability, > with the same applying to square root]). That is indeed a problem, otoh it allows people like me to manually replace explicit 1/sqrt(x) code with _much_, much faster alternatives, and come out looking like a hero for doubling the simulation speed. This was even before both SIMD and hw 1/sqrt(x) lookup tables. :-) Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2011-10-13 00:49 -0700 |
| Message-ID | <4775c736-22ce-48af-b7e8-5587609f996c@g16g2000yqd.googlegroups.com> |
| In reply to | #4170 |
On Oct 13, 2:12 am, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: [snip] > With the current integer situation, (2's complement, no overflow > exceptions or even detection), any overflows don't matter: The result is > still the same independent of evaluation order. I was thinking of an ISA (like MIPS) that can generate overflow exceptions. ISTR reading that C allows signed overflow to generate such exceptions. [snip] > That is indeed a problem, otoh it allows people like me to manually > replace explicit 1/sqrt(x) code with _much_, much faster alternatives, > and come out looking like a hero for doubling the simulation speed. > > This was even before both SIMD and hw 1/sqrt(x) lookup tables. > :-) Out of curiosity, did you ever have opportunity to use partial memoization--by which I mean saving a high precision estimate for one value to reduce the iteration count needed to generate the reciprocal for another value? I do not know anything about seismic simulation, but I am guessing that such might be useful for some astronomical simulation.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-13 10:37 +0200 |
| Message-ID | <8kkim8-2l22.ln1@ntp6.tmsw.no> |
| In reply to | #4171 |
Paul A. Clayton wrote: > On Oct 13, 2:12 am, Terje Mathisen<"terje.mathisen at tmsw.no"> >> That is indeed a problem, otoh it allows people like me to manually >> replace explicit 1/sqrt(x) code with _much_, much faster alternatives, >> and come out looking like a hero for doubling the simulation speed. >> >> This was even before both SIMD and hw 1/sqrt(x) lookup tables. >> :-) > > Out of curiosity, did you ever have opportunity to use partial > memoization--by which I mean saving a high precision > estimate for one value to reduce the iteration count needed to > generate the reciprocal for another value? I've only ever looked into this for numeric integration of a complex function (i.e. working with real, not complex numbers), where the step from one point to the next was quite small. AFAIR the starting guess was extrapolated from the last 2-3 results, but I might misremember, it must have been 20+ years ago. I have never used it for invsqrt(x) though, plain lookup tables do well enough here. > > I do not know anything about seismic simulation, but I am > guessing that such might be useful for some astronomical > simulation. The invsqrt() work was for CFC (computational fluid chemistry), where the reciprocal distance between atoms (ions really) is needed. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2011-10-13 11:04 -0400 |
| Message-ID | <a6Dlq.10949$GR4.8204@newsfe02.iad> |
| In reply to | #4171 |
Paul A. Clayton wrote: > On Oct 13, 2:12 am, Terje Mathisen <"terje.mathisen at tmsw.no"> > wrote: > [snip] >> With the current integer situation, (2's complement, no overflow >> exceptions or even detection), any overflows don't matter: The result is >> still the same independent of evaluation order. > > I was thinking of an ISA (like MIPS) that can generate overflow > exceptions. ISTR reading that C allows signed overflow to > generate such exceptions. x86 does have overflow exceptions with the INTO instruction (trap overflow flag set). INTO probably causes a pipeline stall too. It doesn't have a VAX style global trap enable flag so one has to test after every operation, but global flags have their own problems with mixed checked and unchecked arithmetic. I think Alpha did it right with its separate Add and AddTrapOverflow instructions, though they didn't have multiple operand sizes as x86. IIRC Ada defines such exceptions as 'Transitory' and highly implementation and situation dependent. They can appear and disappear depending on... pretty much anything really. Which is not very helpful as that simply defines them as almost always possible and pretty much unpredictable. e.g. byte i, j, k; k = 127; j = foo(); i = 127 + j - k; If run on an 8 bit cpu then addition can overflow and trap. If run on a 32 bit cpu then j and k are promoted from 8 to 32 bits and cannot overflow on + or -, but a range check on the result is required when demoting to 8 bits to store i. If compiled for an 8 bit cpu but compiler propagates constant k and rearranges expression to coalesce constants, then no + or - ops or overflow trap or result range check. If calculation was in a loop and compiler does not propagate k but does hoist 127 + j out of loop then trap can move to a different location. etc, etc, etc Eric
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2011-10-13 17:15 -0400 |
| Message-ID | <QyIlq.83$Ml3.0@newsfe17.iad> |
| In reply to | #4179 |
EricP wrote: > > x86 does have overflow exceptions with the INTO instruction > (trap overflow flag set). INTO probably causes a pipeline stall too. > It doesn't have a VAX style global trap enable flag so one has > to test after every operation, but global flags have their own > problems with mixed checked and unchecked arithmetic. > > I think Alpha did it right with its separate > Add and AddTrapOverflow instructions, > though they didn't have multiple operand sizes as x86. One other thing I should mention is that Ada requires, and I think you'd want this in any language that includes checks, that the destination not be modified if there is an overflow to avoid storing invalid values into variables. In the case of the x86 that precludes the use all the various instructions that directly update memory, at least for checked operations, because an overflow is checked later by INTO and therefore does not abort the instruction. This forces you to use a load-reg-reg-store style code. Eric
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-14 09:22 +0200 |
| Message-ID | <7i4lm8-bt52.ln1@ntp6.tmsw.no> |
| In reply to | #4188 |
EricP wrote: > EricP wrote: >> >> x86 does have overflow exceptions with the INTO instruction >> (trap overflow flag set). INTO probably causes a pipeline stall too. >> It doesn't have a VAX style global trap enable flag so one has >> to test after every operation, but global flags have their own >> problems with mixed checked and unchecked arithmetic. >> >> I think Alpha did it right with its separate >> Add and AddTrapOverflow instructions, >> though they didn't have multiple operand sizes as x86. > > One other thing I should mention is that Ada requires, > and I think you'd want this in any language that includes checks, > that the destination not be modified if there is an overflow > to avoid storing invalid values into variables. > > In the case of the x86 that precludes the use all the > various instructions that directly update memory, > at least for checked operations, because an overflow is checked > later by INTO and therefore does not abort the instruction. > This forces you to use a load-reg-reg-store style code. On the first hand, the x86 instructions that directly modify memory, basically load-op-store like SUB [EBX],EAX are rarely used in optimized code, since unrolling the operation makes it easier to schedule the three independent parts. On the second hand, at least for the ADD/SUB + INTO style overflow detection, it is in fact possible for the trap handler to undo the operation. The exception to this is when the operation is ADC/SBB, because it is impossible to determine what the previous content of the carry flag was. On the gripping hand most compilers don't actually use INTO anyway, afaik even among those that do support/require overflow handling like Ada? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2011-10-14 13:37 -0400 |
| Message-ID | <rr_lq.4482$kv3.1722@newsfe19.iad> |
| In reply to | #4193 |
Terje Mathisen wrote: > EricP wrote: >> EricP wrote: >>> >>> x86 does have overflow exceptions with the INTO instruction >>> (trap overflow flag set). INTO probably causes a pipeline stall too. >>> It doesn't have a VAX style global trap enable flag so one has >>> to test after every operation, but global flags have their own >>> problems with mixed checked and unchecked arithmetic. >>> >>> I think Alpha did it right with its separate >>> Add and AddTrapOverflow instructions, >>> though they didn't have multiple operand sizes as x86. >> >> One other thing I should mention is that Ada requires, >> and I think you'd want this in any language that includes checks, >> that the destination not be modified if there is an overflow >> to avoid storing invalid values into variables. >> >> In the case of the x86 that precludes the use all the >> various instructions that directly update memory, >> at least for checked operations, because an overflow is checked >> later by INTO and therefore does not abort the instruction. >> This forces you to use a load-reg-reg-store style code. > > On the first hand, the x86 instructions that directly modify memory, > basically load-op-store like SUB [EBX],EAX are rarely used in optimized > code, since unrolling the operation makes it easier to schedule the > three independent parts. Hmmm... yes. The MS C++ compiler does use lots of the different addressing modes, but only for loading registers. With the exception of some stores to temp variables on the stack, all stores are simple moves. Add/sub use reg,reg and reg,[mem] memory as a source but none use [mem],reg as a destination. I hadn't noticed that. > On the second hand, at least for the ADD/SUB + INTO style overflow > detection, it is in fact possible for the trap handler to undo the > operation. > > The exception to this is when the operation is ADC/SBB, because it is > impossible to determine what the previous content of the carry flag was. It would not be acceptable to write an invalid value to a variable then undo it in an exception handler. That variable might could be used before it was undone. If it was a device register, it might trigger an illegal operation. I also see no reason to make exception handling more complicated. > On the gripping hand most compilers don't actually use INTO anyway, > afaik even among those that do support/require overflow handling like Ada? > > Terje > Probably not. The main reason for INTO would be to save code space vs the alternative of Branch Overflow to a exception thrower. However branching approach has the problem of tracing the exception source back to its origin. The advantage of of having the exception thrown right where the error occurs is to facilitate fixing the error. My main objective is not the support of a particular language, e.g Ada or Modula, but a set of tools (instructions) that allow errors to be detected so they can be repaired. One might consider adding new data types to a C compiler to support both checked and unchecked, signed and unsigned arithmetic (with warnings on mixing types). But that's about all one could do with C. Having a set of instructions like AddTrapOverflow, AddTrapCarry, etc doesn't bloat the code with branches and retains the traceability. I suspect it would be easier for the microarchitecture to attach an exception flag to the internal uOp that is recognized at retire (it probably already has this). Given that, as you point out, the compilers are generating load-reg-reg-store style code already, one could make a case that these XxxTrapOverflow/Carry instructions need only operate on full width registers, 32 bits for x86 and 64 bits for x64, and do not need all the various addressing modes. This cuts way down on the op code space required for support. Eric
[toc] | [prev] | [next] | [standalone]
| From | "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2011-10-13 11:11 -0700 |
| Message-ID | <4E9729E2.6090607@SPAM.comp-arch.net> |
| In reply to | #4167 |
On 10/12/2011 11:15 PM, Paul A. Clayton wrote: > [Newsgroups trimmed] > On Oct 12, 10:48 pm, Andrew Reilly<areilly...@bigpond.net.au> wrote: > [snip] >> Nick's point (I believe) is that floating point arithmetic is fraught, >> because it is fairly fundamentally unlike the mathematics that expression- >> based languages appear to be offering. In maths and exact computer >> arithmetic (eg integer), addition is associative and a bunch of other >> nice rules for "simplification" apply. > > Unless the environment provides promotion to larger precision, > integer arithmetic cannot be reordered arbitrarily. E.g., d = a + b + > c > could overflow in one evaluation order but not in another ordering. But as I am sure has already been pointed out, most machines have 2's complement wrapping arithmetic. And do not trap on overflow. Which means that even if it overflows in one evaluation order (a+b)+c rather than a+(b+c), you will still get the same answer. And it will not even necessarily be incorrect. --- Don't get me wrong: I am a big advocate of detecting integer overflow.
[toc] | [prev] | [next] | [standalone]
| From | Al Grant <algrant@myrealbox.com> |
|---|---|
| Date | 2011-10-14 01:04 -0700 |
| Message-ID | <668c136e-28a6-4d27-b487-9fa2b3083228@f13g2000vbv.googlegroups.com> |
| In reply to | #4183 |
On Oct 13, 7:11 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net> wrote: > But as I am sure has already been pointed out, most machines have 2's > complement wrapping arithmetic. And do not trap on overflow. But a C implementation isn't obliged to make that part of its contract with the programmer. It can leave overflow as undefined. This can then be used in optimizations, e.g to optimize away if (n+1 > n) ... if n is signed. That doesn't look very realistic written like that, but some loop optimization cases reduce to something similar. Essentially there are at least three possible "contracts" for signed arithmetic overflow in C - i.e. wrap, trap, or undefined. Some compilers offer all three as options. Saturation would be another possibility, though slow on most architectures.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.arch
csiph-web