ANSII C, optimization, and "hardware registers"

[Alan Lehotsky]

APOLLO's implementation of C has support for both the notion of
memory being shared between asynchronous activities (VOLATILE)
and memory-mapped i/o (DEVICE).  Rather than implement these as
storage classes, we chose to create an "extensible" extension
mechanism with an attributes list.

The semantics of VOLATILE are based on the notion that the
named variable can be modified between any two references, so
that the variable may not be a component of any common subexpression,
nor may it be hoisted out of a loop.

DEVICE implies more stringent conditions on the optimizer and code
generator. (Still somewhat of a DWIM [Do What I Mean] situation, though)
In addition to implying VOLATILE, it indicates that extra references
by the compiled code will be MOST unwelcomed.  As an explicit example,
a DEVICE location will never be the target of a CLR instruction by the
68000 code generator, as this instruction does a READ-MODIFY bus cycle!
(which can really annoy some of the dumber write-only Multibus peripheral
cards!)

The flavor of the syntax for this extension is

       int devreg #attribute[volatile];
      
      short outmask #attribute[device(write)],
            inmask #attribute[device(read)];

(NO FLAMES ABOUT HERETICAL VIOLATIONS OF THE K&R "BIBLE", PLEASE)

We also support an "ADDRESS(expr)" attribute which allows a name to
be associated with a compile-time constant expression which denotes
a memory address.

All of the above functionality also appears in our PASCAL, with
different syntax (similar to VAX-11 PASCAL's attributes).  The
implementation and semantics of this was based on very similar
work I implemented in DIGITAL's common BLISS compilers in the late
70's.  (Just another example of BLISS being a much better system's
programming language than C will EVER be.....)