Re: how to avoid a memset() optimization

Joachim asked:
> Did these tools honor "volatile" modifiers? I'd assume that for the MIPS
> compiler suite, but it's hard to imagine that for an OM-style optimizer.


John (the moderator) added:
> Same question for the other sequence point stuff.


I don't know for certain, but I doubt it. The MIPS internal
representation was based upon a modified P-code (Pascal) compiler and
I doubt it had a notation for don't move this across this boundary--at
least I don't remember one in the parts of the optimizer I worked on.


However, in the OM code, since it was based upon the hardware/OS spec
and there was a "memory barrier" instruction, which it was illegal to
move memory accesses across. Thus, one could construct programs that
had "sequence points" or protect "volatile" locations.


I don't know to what extent those instructions were supported at the
high-level language interface (certainly one could stick in inline
assembly to do so), but did the compilers generate memory barriers for
sequence points or around volatile accesses? I would doubt that they
did.


Of course, I also doubt that OM was considered to be part of the ANSI
conforming tool chain for C or FORTRAN anyway, since only certain
specific compiler options settings were listed as being ANSI
conformant, and other combinations did not promiss conformance. (I'm
certain that the optimization level that turned on "whole program"
optimization was not part of the ANSI conformant switches.)


That also brings up the whole question of benchmarksmanship. The
compiler options used in running the benchmarks were not the same ones
used for promising ANSI conformance (nor even the same across all
benchmarks). Then again, neither set of options necessarily matched
the ones typical users would have used to compile their programs
either. On the other hand, if one availed oneself of the benchmark
center, there were engineers that would give some help in tuning ones
application and thus finding the right combination of switches, if one
cared enough.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
------------------------------------------------------------------------------

Return to the comp.compilers page.
Search the comp.compilers archives again.