Re: Evolution of PL/I
- From: "John W. Kennedy" <jwkenne@xxxxxxxxxxxxx>
- Date: Fri, 26 May 2006 14:39:36 -0400
Tom LINDEN wrote:
On Wed, 24 May 2006 19:51:31 -0700, John W. Kennedy <jwkenne@xxxxxxxxxxxxx> wrote:
Tom LINDEN wrote:doesn't matter. either it is a constant or it is an expression. YouOn Wed, 24 May 2006 12:21:14 -0700, glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx> wrote:
I wrote this one thinking that changes to L would take effect withinDoesn't matter, the optimization is the samer anyway.
the loop, but in any case with the ABS the compiler can be sure that the increment is never negative, and optimize accordingly.
It can't be the same. The /meaning/ of BY depends on the sign.
create the trees and the optimizer will do what it can, maybe fold constants,
create shadow variables, many things. You may end up generating differnet instructions sequences depending on the architecure. VAX had, for example,
a single instruction that did, add compare and branch. On risc machines
it is more cumbersome
The problem is that what comparison is done depends on the sign of the BY. In principle, a compiler that knows that the BY is positive (or negative) can create a single test and branch. A compiler that does not know the sign of BY must either use a special add-and-compare-and-branch-if-high-if-addend-is-positive-or-branch-if-low-if-addend-is-negative instruction (I don't know of any architecture that includes one), or else must use two nested branches, or play around with something like the EX instruction or a nested subroutine call, any one of which is likely to upset pipelining.
On any machine I know, 'BY ABS(expression)' is theoretically capable of better optimization, possibly massively better optimization, than is 'BY expression', except where 'expression' is UNSIGNED.
--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
.
- Follow-Ups:
- Re: Evolution of PL/I
- From: Tom Linden
- Re: Evolution of PL/I
- References:
- Re: Evolution of PL/I
- From: robin
- Re: Evolution of PL/I
- From: Peter Flass
- Re: Evolution of PL/I
- From: glen herrmannsfeldt
- Re: Evolution of PL/I
- From: robin
- Re: Evolution of PL/I
- From: James J. Weinkam
- Re: Evolution of PL/I
- From: glen herrmannsfeldt
- Re: Evolution of PL/I
- From: Tom LINDEN
- Re: Evolution of PL/I
- From: John W. Kennedy
- Re: Evolution of PL/I
- From: Tom LINDEN
- Re: Evolution of PL/I
- Prev by Date: Re: MAPPING OF STRUCTURES
- Next by Date: Re: LOOP CODE
- Previous by thread: Re: Evolution of PL/I
- Next by thread: Re: Evolution of PL/I
- Index(es):
Relevant Pages
|