rbbb@rice.EDU (04/13/87)
Let me try again (last time, the machine saw the message coming and crashed). I am bothered by the two rules (roughly stated) (1) parentheses are used for parsing, not specifying evaluation order and (2) the compiler CANNOT associatively rearrange across statements. Taken together, these DO provide control over order of evaluation, but I think it is a bad solution. (1) is too loose for floating point arithmetic and the proposed solutions are ugly. This has been argued by several people, though ugly is of course in the eye of the beholder. (2) is over-restrictive for integer arithmetic, which (as far as I know) does not generate overflow exceptions. (2) might be justified by "but I need control over order of evaluation in my device driver". This is not a good argument, except for old code, because the "volatile" keyword should take care of this. If it does not, then "volatile" should be looked at again. Old code is also not a problem, because there are old compilers. If the more aggressive (i.e, incompatible with old code) rearrangements are only applied by the optimizer, I think people can get by (if the code fails, run it unoptimized until you can figure out where to insert "volatile" to make it compile correctly). I also object to this style of specification because it seems that the committee is trying to specify a *compiler*, not a *language*. (I am afraid that I must infer this, because I don't have a copy of the specification). It is appropriate to specify a compiler if you have also specified an abstract machine for which the compiler generates code, but I don't think that this is the case here. Some sort of "abstract machine" might also be useful in making clear exactly what "volatile" means. David