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

[presotto@plan9.bell-labs.com]

My probably incorrect 2 cents.  I think the basic problem is
bigger than volatile's power to solve.  There is no silver bullet.

My only experience with volatile was trying to make inferno emu code
run when compiled with non-plan9 compilers.  I never did figure out
everywhere it was needed.  Our waserror()/nexterror() stuff completely
blew away optimizing compilers since they are essentially longjumps.
Therefore, the compilers didn't know the active scope of a variable
so that registerization (and other opts) broke the code.  The appropriate
application of volatile fixed the problem though appropriate seemed
to be different for each compiler.  The general rule of thumb was that
any variable used by the waserror block should be volatile.  This seemed
to work in most instances but not all.  We had afternoons of sitting around
the Unix room trying to define exactly what it was that volatile
did in different compilers.  I never felt safe about the emu code
because of it.

My three main conclusions from this were:
1) waserror/nexterror is definitely evil unless understood by the
 compiler and perhaps even then.  It's a step outside the language
 definition and therefore a dangerous step to take.  We were
 comfortable with it in Plan 9 because we controlled the compilers
 but it became tortuous when someone else controlled them.

2) Volatile's meaning needs to grow to encompass the optimization
 du jour (don't registerize, don't optimize away memory accesses,
 don't optimize away condition code changes, don't inline code
 that contains it, ...) or we need more constructs.  It's hard to
 not screw up when using a construct whose meaning requires an in
 depth knowledge of what the compiler does.  To a certain extent, knowing
 the compiler's properties is a prerequisite to working in a kernel
 but there's a limit to what you have to understand.

 I'ld be happy if volatile just meant what I think it was originally
 intended for: don't optimize away or reorder any memory references.
 However, that in itself has myriad side effects.
 People will start to use it to avoid loop unrollings etc not envisioned
 by the compiler writer.

3) I'm too stupid to understand what C has become.  Perhaps I should go back
 to assembler.  Oops, I'm way to stupid to understand what ken's
 assembler does, I should go back to 1's and 0's.

The idea that compiler optimization is a knob that you turn till some
assumption you made becomes incorrect is scarey to me.  Very few
people understand the languages they use well enough to know when
they're treading on dangerous ground.  Even fewer testing environments
are complete enough to notice when something really has broken such
as the inadvertant creation of covert channels that got this started.
Luckily incorrect behavior in most programs doesn't really matter
because what most programs do is pretty ill defined.