James Giles wrote:
> My own bias is that the only transformations that should be allowed
> are either those which entirely preserve the semantics of the original
> program or those explicitly permitted by the standard (mathematically
> equivalent transformations within a single expression that don't invade
> the integrity of parenthesis). This is because I really would like to
> move toward that ideal world where optimization was entirely a
> pragmatic issue.
I don't understand this: whether is "pragmatic" or not, if the standard
says you can only do what you propose, how can it do otherwise?
Where will it all end? This would prevent "inlining" of procedures
because (unless some other strange things have been done to the
standard), I don't think there is any place that allows it. In fact,
there are explicit words to the effect that a CALL statement is executed
by executing the subroutine.
I was sufficently depressed by Keith's reporting that "Interp #1"
(sorry, I wasn't aware of it) doesn't allow code to be moved that I
wasn't going to comment further, but this is really ridiculous. If
that is, in fact, the result of an interpretation, J3 has instantly
made every compiler (that I would buy) nonstandard and gone against
the collected wisdom of implementors and former incarnations of the
standards bodies. A little history (unfortunately, forgetting it
did not simply cause it to be repeated, but repealed 8^):
At a meeting during development of Fortran 90, somebody rasied just
this issue. A straw vote was taken (40-1, if I recall) that the
intent of the standard was to allow code movement. I tried to get
some words put into the standard, but it was so obvious to everybody
that they decided the words were not necessary. And so look at the
consequences!
My understanding of words in the standard that say that statements
are executed in the order written (sans branches, etc, of course) and
that CALL statements are exectued by going to the first executable
statement of the subroutine is that this describes the semantics
(maybe not in the sense James is using the term) or "intended results"
or some such, and that the compiler is free to generate any code that
produces that result (not counting variations in precision, etc.)
I would recommend that J3 change this interpretation quickly before
somebody takes it seriously.
--
Walt Brainerd [log in to unmask]
Unicomp, Inc. +1-520-298-7212 298-7074 (fax)
7660 E. Broadway, Suite 308 888-330-6060
Tucson, AZ 85710 USA http://www.uni-comp.com
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|