Numeric comparisons

[Dick Dunn]

> > Compiler users note -- if your compiler gives the wrong results, the
> > compiler writer might not be completely at fault.  Many early CPU
> > chips (8080A, Z80, 6502, etc.) did comparison by subtraction, and a
> > compiler would have had to generate extra code to test for Overflow
> > in order to get the correct result.

Oomph!  Point of philosophy, yer honner--it is NOT the job of the compiler
writer to transmit shortcomings of the processor into language problems.
If the chip does the comparison "wrong" (in some cheap way), the compiler
writer needs to sort it out so that the language implementation gives the
right answer.

I once complained about the implementation of certain comparison
operations in a well-known language on a well-known processor--the problem
was that it was possible to find values a, b, c such that all of a<b, b<c,
and c<a were true!  The response I received, from the well-known designer
of this well-known language (and no, obviously this wasn't C!) was
something to the effect that "we decided not to implement [the correct
comparison code] thereby trying to correct the unprofessional design of
the computer by an inefficient implementation.  Whether this decision was
right, I do not know."  Well, he didn't know, but I did (and do).  If it
ain't right, it's wrong (except in quantum mechanics and politics), no
matter how efficient it is.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...Lately it occurs to me what a long, strange trip it's been.