Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn )
Newsgroups: net.lang.c
Subject: Re: ANSII C, optimization, and "hardware registers"
Message-ID: <5341@brl-tgr.ARPA>
Date: Tue, 16-Oct-84 19:41:44 EDT
Article-I.D.: brl-tgr.5341
Posted: Tue Oct 16 19:41:44 1984
Date-Received: Thu, 18-Oct-84 00:47:11 EDT
References: <1538@wateng.UUCP>
Organization: Ballistic Research Lab
Lines: 24

> Well, imagine my surprise when the code generated only did:
> 	1.  loaded the ST_START value into CPU register (byte value actually)
> 	2.  placed the CPU register value into memory (word value)
> 	3.  Did not generate a test instruction, cause the ST_START and
> 		ST_DONE value were identical.
> 
> Now here is the question:
> 1.  Was this legal code generation?
> 2.  Note that this compiler did "simple" optimizations as part of the code
> 	generation. Is this legal?

Step 2 of the generated code was sloppy but legal... incomplete optimization.

Optimizations certainly are legal, but your C compiler needs an escape
to avoid the sort of over-optimization you have described.  Frequently
this is done by testing for references that can be seen at compile time
to be possible "I/O page" addresses and skip optimizations for them.
The given example would not have been detected under this test since the
CSR variable was loaded at run-time, not compile-time.

The ANSI C committee was supposed to be considering this issue; the
BLISS-style "volatile" type modifier was mentioned as one possibility.
(This tells the compiler not to optimize any expression containing
the variable so flagged.)  I don't know the outcome of the discussions.