3 Dec
2010
3 Dec
'10
3:22 p.m.
On Dec 3, 2010, at 3:10 PM, Fred Cisin wrote:
Some of these threads go on long enough it's hard to remember how it started. ;-)
> Whether a
programmer or a compiler produce better code would seem to
> depend on how well one can get the compiler to understand all of the
> details of what one WANTS the code to do, and just how weird THAT might
> be. Some things, such as deliberately wasting time, or polling a memory
> location that is influenced externally, need additional explanation for
> the compiler to understand not to optimize them out.
On Fri, 3 Dec 2010, Guy Sotomayor wrote:
See my previous post. Using the volatile keyword
on a variable requires
the compiler to read/write it as expressed in the program (ie if in a
loop, the compiler can't just read it once and be done). If the
compiler doesn't do that, it's a bug if it in any way claimed be a
standards compliant compiler.
You are absolutely correct.
If there is a VOLATILE keyword, and the compiler ignored it, then that is
certainly a bug. There is certainly no argument about THAT.
But, see MY previous posts.
My ORIGINAL post (the origin of this sub-thread) was that the first
attempt at an optimizing compiler from Microsoft DID NOT HAVE a VOLATILE
keyword.
That was a mistake!
"Standards compliant"??
I'm talking about before that, when "standards compliant" was a CLAIM that
it was "K&R".
One of (many of) the problems with "K&R" was that it assumed that there
would be no significant optimization. I'd argue that this was a bit short sighted
since at the time there were a number of optimizing compilers out. Some of them were used
for systems implementation and had to deal with this very issue. I actually recall the
surprise in the early days of BLISS-11 when it optimized out a whole chunk of I/O polling
code...it then had to be "taught" about PDP-11 MMIO and that it had to do all of
the loads/stores as written.
TTFN - Guy