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.