Re^2: Turbo C 2.0 vs MSC 5.1

[P E Smee]

In article <527 at tigger.planet.bt.co.uk> raph at tigger.planet.bt.co.uk (Raphael Mankin) writes:
>
>I a Coral 66 compiler that I wrote some 17 years ago I went to great
>lengths to preserve arithmetic precision, including transforming
>things like
>		a/b/c/d/e
>into
>		a/(b*c*d*e)
>and re-ordering factors so as to do division as late as possible.

A bad move, I'd have said.  It is not difficult to think of cases where
'a/b/c/d/e' would give a sensible answer, while 'a/(b*c*d*e)' will
overflow computing the denominator '(b*c*d*e)' and so give nonsense.

Further, the person writing that might have set up condition (or fault,
or signal, take your pick) handlers to catch the hardware conditions that
might result from the repeated division (at a higher level invisible to
the compiler) based on knowledge of likely values/errors.  The reordering
changes the sorts of faults which are likely to occur.

(Having both written and used compilers myself) I'd suggest that it is
generally a bad idea for a compiler to 'rewrite' expressions unless the
rewrite is both mathematically identical in an ideal world, and
pragmatically identical given the range of numbers the machine can
express, and the sorts of faults which will occur with any set of input
values.

(Although, being paranoid, I'd also suggest that the person writing
a/b/c/d/e should inject lots of ()s to indicate that the ordering is
really desired.  I tend to parenthesize everything :-)  Goes without
saying that I strongly feel that languages should honor any order-of-
evaluation requirements which the programmer specifies using parens.