low level optimization

[Blair P. Houghton]

In article <22392 at lanl.gov> jlg at cochiti.lanl.gov (Jim Giles) writes:
>bhoughto at hopi.intel.com (Blair P. Houghton) writes:
>> for three days when we say it is most definitely NOT
>> dependent on the source language?
>
>Whoops!  Forgot to mention: NCEG is also affiliated with WG14 (the
>ISO C working group).  So you better set those guys straight too.
>(It couldn't be that these people know something that Blair Houghton
>doesn't?  Nah - no chance.)

The thing they know that I don't is a good reason why it
should be necessary to force certain data into a
non-aliased paradigm rather than trusting the programmer to
keep certain data from being aliased.  The best bad reason
is that standards are better at enforcement than
documentors are.

It's neither my fault, my concern, nor my problem that
they're chasing pots of dingy gold at the end of haggard
rainbows, and I certainly don't want to be taxed for it
later by having to pay an extra $20 per copy of the
Standard for 100 pages of errata explaining the contortions
one must go through to define a non-aliasing implementation.

They can elide the trigraphs sections while they're at it, too.

Their best bet is to do what we've all done:  wait for a few
examples of prior art, and then choose from the good ones.
It's a perpetual fool's chase, trying to design by committee
what should be designed by evolution.

X3.159-1989 shows in spots the effects of this political
methodology to science, and I'm thrilled to say that the
noalias crock isn't one of the mistakes they made.

				--Blair
				  "If you want f77(1), you
				   know where to find it."