Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site opus.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!nbires!opus!rcd
From: rcd@opus.UUCP (Dick Dunn)
Newsgroups: net.lang.c
Subject: Re: Numeric comparisons
Message-ID: <56@opus.UUCP>
Date: Wed, 18-Sep-85 02:32:18 EDT
Article-I.D.: opus.56
Posted: Wed Sep 18 02:32:18 1985
Date-Received: Fri, 20-Sep-85 04:06:17 EDT
References: <10176@ucbvax.ARPA> <5118@mit-eddie.UUCP> <693@terak.UUCP> <160@graffiti.UUCP>
Organization: NBI,Inc, Boulder CO
Lines: 26

> > 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