On (11 Aug 97) Gerry Danen wrote to Erik Warmelink...
[ talking about the `volatile' keyword ]
 GD> I don't understand why all screen output would be removed due to
 GD> optimization.  Can you explain, please?
Most compilers have an optimization called dead code elimination.  This
analyzes the code to figure out whether there's code that can never
possible execute.  This can come in handy in a situation like:
    if (sizeof(int) < 4)
        do_this();
    else
        do_that();
Now, obviously the size of an int can't change during run time.  What
you're doing is nearly the sort of thing you'd typically do with the
preprocessor, but you can't use sizeof() in a #if, so you'd have to
change things considerably to let the preprocessor handle this.
The alternative is for the compiler to eliminate the code that's never
going to get used, as well as eliminating the code for an if() that's
always going to make the same decision.
Some compilers that do relatively sophisticated analysis can also
determine that some variable you're writing to never actually has that
result used.  In this case, they again eliminate the code that writes to
that variable.
The problem arises with writing to the screen because it appears to the
compiler that what you write to the screen never gets read again.
Therefore the compiler assumes that the result was never used, and
optimizes out the code that does the writing.  Obviously here we run
into a problem: even though you (nearly) never have code that reads
values from the screen buffer, YOU read the output on the screen.  You
have to inform the compiler that the act of writing to this memory is
important EVEN when it appears to the compiler to accomplish nothing.
A similar situation arises when something other than the program can
modify some memory.  Under normal circumstances, a program is free to
assume that if it writes something into a memory location, it'll get the
same value back out if it reads that same location.  Likewise, it's free
to assume that if it reads one value one time, that unless it writes to
that location, it'll get the same value if it reads the same location
again.
This is an important optimization: it's MUCH faster to store those
values in registers when possible.  However, if you're dealing with
something like the keyboard buffer, it doesn't apply.  For instance, if
you read the keyboard buffer pointers one time, they might indicate that
no key has been pressed.  After you press a key, one of the pointers
will change to indicate that a key HAS been pressed.  Each time you want
to check for a keypress, you have to read the data from memory - you
can't simply assume that if you read it once, it won't change until the
program changes it. (most programs will NEVER change it, but it changes
constantly, each time the user presses a key on the keyboard.)
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------