Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!cmcl2!brl-adm!adm!rbbb@rice.EDU
From: rbbb@rice.EDU (David Chase)
Newsgroups: comp.lang.c
Subject: Beating a dead horse
Message-ID: <7900@brl-adm.ARPA>
Date: Thu, 18-Jun-87 00:19:46 EDT
Article-I.D.: brl-adm.7900
Posted: Thu Jun 18 00:19:46 1987
Date-Received: Sun, 21-Jun-87 15:42:06 EDT
Sender: news@brl-adm.ARPA
Lines: 44

Several weeks or months ago, there was a lot of noise about floating point
in C.  I eventually ignored it because I had better things to do, but
several thoughts keep returning to me, and I thought I would "share" them
with you.

1) Listening to quotes from the draft standard and K&R, it seems that a
lot of people (including the authors of the standard, perhaps) don't
understand the difference between a LANGUAGE specification and a COMPILER
specification.  If you tell me that I cannot put optimization X in my
compiler, you are not telling me about the language.  The only (proper)
use for a compiler description in a language specification is if you have
a well-defined, simple abstract machine for which the well-defined, simple
compiler generates code.  There is also a well-defined, simple way to
"observe" the behavior of the abstract machine (as opposed to reading off
the bits--if you could see all of the abstract machine, all C compilers
everywhere would always generate exactly the same bits).  You tell me what
the LANGUAGE is, and I'll write compilers and be sure that they are
correct.

2) There seems to be (again, I am inferring this) an extraordinary amount
of vagueness regarding the properties of integers.  Is there an overflow
exception or not?  What about divide-by-zero?  Tell me what arithmetic
means (dammit!), not whether or not I am free to rearrange expressions
across statement boundaries.

2a) How should exceptions be treated?  The rule of thumb that I like to
use is that the compiler can never increase the number of exceptions
generated.  A compiler must be careful with the rearrangement of
exceptions because the program can change the way that they are handled.

3) Machine floating point arithmetic is not the same as machine integer
arithmetic.  It is stupid to pretend otherwise.

4) I think that "sequence points" are a botch.  The parallelizing compiler
guys have it right; access to volatile variables represents INPUT and
OUTPUT.  Optimization of a program is not allowed to change the I/O
behavior of a program.  A program, when run, generates a stream of "I/O
events" which correspond to reading and writing of volatiles.

I realize that this is pretty late in the game for this sort of criticism,
but I wanted to be sure that you people knew something was wrong.  It's
not like anything I've written here is new, after all.

David