Re: [9fans] how to avoid a memset() optimization

[Dennis Ritchie <dmr@plan9.bell-labs.com>]

Gwyn remarked

 > C as you imagine it was never really in existence; even on
 > the PDP-11, certain access patterns (such as dereference
 >  of constants in the range 0160000-017777t) were specially
 > (kludge) excluded from optimization, so that device drivers
 > wouldn't be broken by non-1-to-1 translations from source
 > code to accesses.

This wasn't true for the PDP-11 compiler, which
(approximately) treated everything as volatile in the
current sense, though it could do some elementary
dead-code elimination.  The (early) BSD/VAX assembly
optimizer did have something like this, however, in that it
avoided certain instructions that wouldn't work in the I/O
space.

 > "volatile" addresses such issues as
 > well as we could with a simple portable mechanism.

The C90 and C99 semantics of volatile remain a bit flabby,
though it would take a lot of work to get a standard
that captured the behavior.  It's been tried.

The intent of volatile was to capture appropriate
behavior of memory-mapped registers and similar
things (like a clock in user space updated by the
OS.)  So, things like

	*p = 0;
	*p = 0;

should generate two stores if p is volatile *int.

One thing added in C90 was volatile's use in proper preservation
of values of automatics in the presence of
setjmp/longjmp. This was a non-issue for the PDP-11
because of details of its calling sequence, harder but
not impossible for the VAX because of its more complicated
(and slow) calling sequence, a real mess with the
advent of RISCs and optimization.  This is presumably
what hit Dave etc. with the setjmp-like waserror/nexterror
(the compiler didn't trigger on those words the
way they're supposed to on setjmp/longjmp).

	Dennis