rbbb@rice.EDU (David Chase) (06/18/87)
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
henry@utzoo.UUCP (Henry Spencer) (06/25/87)
> 2) There seems to be (again, I am inferring this) an extraordinary amount > of vagueness regarding the properties of integers. This is because C is, above all, a language in which one can write efficient code. This means that the properties of integers in a given implementation have to match those of the machine fairly closely, and the machines vary! > Is there an overflow exception or not? What about divide-by-zero? My machine has neither. Some have both. So the answer is "maybe". -- "There is only one spacefaring Henry Spencer @ U of Toronto Zoology nation on Earth today, comrade." {allegra,ihnp4,decvax,pyramid}!utzoo!henry