Re: Automatically transform or expand do loop in a subroutine

This is a discussion on Re: Automatically transform or expand do loop in a subroutine within the pl1 forums in Programming Languages category; Gordon Sande wrote: (snip) > Some compilers have options to unroll loops as part of their stronger > optimization strategies. Read the compiler documentation carefully. > This capability is more likely to be present in commercial compilers that > make a point of providing fast executables. As opposed to being free or > having good debugging. Some compilers will even inline small user functions > as part of their stronger optimization. If optimizing were truly important > for you I would expect that you would have current versions of several > compilers rather than one which has not been supported ...

Go Back   Application Development Forum > Programming Languages > pl1

Object Mix

Register FAQ Calendar Search Today's Posts Mark Forums Read
  #1  
Old 01-31-2008, 02:54 PM
glen herrmannsfeldt
Guest
 
Default Re: Automatically transform or expand do loop in a subroutine

Gordon Sande wrote:

(snip)

> Some compilers have options to unroll loops as part of their stronger
> optimization strategies. Read the compiler documentation carefully.
> This capability is more likely to be present in commercial compilers that
> make a point of providing fast executables. As opposed to being free or
> having good debugging. Some compilers will even inline small user functions
> as part of their stronger optimization. If optimizing were truly important
> for you I would expect that you would have current versions of several
> compilers rather than one which has not been supported for several years.


Loop unrolling was one of the favorite examples of the power
of the PL/I preprocessor. I don't know that anyone actually
used it in real code, though. The simplest form, something like:

%DECLARE I FIXED;
%DO I = 1 TO 10;
Z(I)=X(I)+Y(I);
%END;
%DEACTIVATE I;

will expand into 10 assignment statements.

Using a preprocessor variable, one could unroll only for
smaller values of N.

DCL J FIXED;
%DCL (I,N) FIXED;
%N=3; /* change N here */
%IF N<=10 THEN %DO I=1 TO N;
Z(I)=X(I)+Y(I);
%END;
%ELSE %DO;
DO J=1 TO N;
Z(J)=X(J)+Y(J);
END;
%END;
%DEACTIVATE I,N;

which will unroll for N<=10, but generate a
real DO loop for larger N.

There is work on a GNU PL/I compiler.
I don't know the status of its preprocessor.

-- glen

Reply With Quote
  #2  
Old 01-31-2008, 03:31 PM
James Giles
Guest
 
Default Re: Automatically transform or expand do loop in a subroutine

glen herrmannsfeldt wrote:
....
> Loop unrolling was one of the favorite examples of the power
> of the PL/I preprocessor. I don't know that anyone actually
> used it in real code, though. The simplest form, something like:
>
> %DECLARE I FIXED;
> %DO I = 1 TO 10;
> Z(I)=X(I)+Y(I);
> %END;
> %DEACTIVATE I;
>
> will expand into 10 assignment statements.


The old LWG Fortran proposal (1982) had something similar,
although it was called "compile-time computations" and not
a preprocessor:

.ifact = 1
.do i = 1, 5
.ifact = ifact*i
A(i) = B(i) / ifact
.end do

This would turn into the following 5 lines:

A(1) = B(1) / 1
A(2) = B(2) / 2
A(3) = B(3) / 6
A(4) = B(4) / 24
A(5) = B(5) / 120

The variables ifact and i are both compile-time varaibles
and don't even exist at run-time. Note that the syntax depends
on the fact that no ordinary Fortran statement can begin with a
period.

I think that the compile-time variables should be explicitly
distinguished from run-time ones, perhaps with a leading
underscore or something. Otherwise I think this idea,
and even this syntax, has some merit.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare


Reply With Quote
  #3  
Old 02-01-2008, 06:35 AM
robin
Guest
 
Default Re: Automatically transform or expand do loop in a subroutine

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:JKydnWLn472ouz_anZ2dnUVZ_jqdnZ2d@comcast.com. ..
> Gordon Sande wrote:
>
> (snip)
>
> > Some compilers have options to unroll loops as part of their stronger
> > optimization strategies. Read the compiler documentation carefully.
> > This capability is more likely to be present in commercial compilers that
> > make a point of providing fast executables. As opposed to being free or
> > having good debugging. Some compilers will even inline small user functions
> > as part of their stronger optimization. If optimizing were truly important
> > for you I would expect that you would have current versions of several
> > compilers rather than one which has not been supported for several years.

>
> Loop unrolling was one of the favorite examples of the power
> of the PL/I preprocessor. I don't know that anyone actually
> used it in real code, though. The simplest form, something like:
>
> %DECLARE I FIXED;
> %DO I = 1 TO 10;
> Z(I)=X(I)+Y(I);
> %END;
> %DEACTIVATE I;
>
> will expand into 10 assignment statements.


This form of DO statement is not permitted
(unless it has been implemented in later versions of
VA PL/I).




Reply With Quote
  #4  
Old 02-01-2008, 07:24 AM
Peter Flass
Guest
 
Default Re: Automatically transform or expand do loop in a subroutine

robin wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:JKydnWLn472ouz_anZ2dnUVZ_jqdnZ2d@comcast.com. ..
>
>>Gordon Sande wrote:
>>
>>(snip)
>>
>>
>>>Some compilers have options to unroll loops as part of their stronger
>>>optimization strategies. Read the compiler documentation carefully.
>>>This capability is more likely to be present in commercial compilers that
>>>make a point of providing fast executables. As opposed to being free or
>>>having good debugging. Some compilers will even inline small user functions
>>>as part of their stronger optimization. If optimizing were truly important
>>>for you I would expect that you would have current versions of several
>>>compilers rather than one which has not been supported for several years.

>>
>>Loop unrolling was one of the favorite examples of the power
>>of the PL/I preprocessor. I don't know that anyone actually
>>used it in real code, though. The simplest form, something like:
>>
>> %DECLARE I FIXED;
>> %DO I = 1 TO 10;
>> Z(I)=X(I)+Y(I);
>> %END;
>> %DEACTIVATE I;
>>
>>will expand into 10 assignment statements.

>
>
> This form of DO statement is not permitted
> (unless it has been implemented in later versions of
> VA PL/I).
>


Nut sure about the current compiler either. I used to do this by coding
the increment, and doing the test via an 'if' statement.

Reply With Quote
  #5  
Old 02-01-2008, 02:36 PM
glen herrmannsfeldt
Guest
 
Default Re: Automatically transform or expand do loop in a subroutine

robin wrote:
(snip, I wrote)

>>Loop unrolling was one of the favorite examples of the power
>>of the PL/I preprocessor. I don't know that anyone actually
>>used it in real code, though. The simplest form, something like:


>> %DECLARE I FIXED;
>> %DO I = 1 TO 10;
>> Z(I)=X(I)+Y(I);
>> %END;
>> %DEACTIVATE I;


>>will expand into 10 assignment statements.


> This form of DO statement is not permitted
> (unless it has been implemented in later versions of
> VA PL/I).


That was cut/paste directly from:

http://publibfp.boulder.ibm.com/cgi-...ol004/20.1.8.3

the same example is in:

http://www.bitsavers.org/pdf/ibm/360...gSpc_Jul66.pdf

from 1966. Maybe VA removed this feature?

-- glen

Reply With Quote
  #6  
Old 02-01-2008, 08:04 PM
CG
Guest
 
Default Re: Automatically transform or expand do loop in a subroutine

On 02/01/08 02:36 pm, glen herrmannsfeldt wrote:
> robin wrote:
> (snip, I wrote)
>
>>> Loop unrolling was one of the favorite examples of the power
>>> of the PL/I preprocessor. I don't know that anyone actually
>>> used it in real code, though. The simplest form, something like:

>
>>> %DECLARE I FIXED;
>>> %DO I = 1 TO 10;
>>> Z(I)=X(I)+Y(I);
>>> %END;
>>> %DEACTIVATE I;

>
>>> will expand into 10 assignment statements.

>
>> This form of DO statement is not permitted
>> (unless it has been implemented in later versions of
>> VA PL/I).

>
> That was cut/paste directly from:
>
> http://publibfp.boulder.ibm.com/cgi-...ol004/20.1.8.3
>
> the same example is in:
>
> http://www.bitsavers.org/pdf/ibm/360...gSpc_Jul66.pdf
>
> from 1966. Maybe VA removed this feature?


From the Enterprise PL/I V3.7 LRM description of:
> %DO Statement
> . . .
> Note: All the formats of the DO statement are supported except:
> * UPTHRU and DOWNTHRU are not accepted.
> * The specification in Type 3 DO statements cannot
> be specified multiple times.


Carl
Reply With Quote
  #7  
Old 02-01-2008, 11:46 PM
John W. Kennedy
Guest
 
Default Re: Automatically transform or expand do loop in a subroutine

robin wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:JKydnWLn472ouz_anZ2dnUVZ_jqdnZ2d@comcast.com. ..
>> Gordon Sande wrote:
>>
>> (snip)
>>
>>> Some compilers have options to unroll loops as part of their stronger
>>> optimization strategies. Read the compiler documentation carefully.
>>> This capability is more likely to be present in commercial compilers that
>>> make a point of providing fast executables. As opposed to being free or
>>> having good debugging. Some compilers will even inline small user functions
>>> as part of their stronger optimization. If optimizing were truly important
>>> for you I would expect that you would have current versions of several
>>> compilers rather than one which has not been supported for several years.

>> Loop unrolling was one of the favorite examples of the power
>> of the PL/I preprocessor. I don't know that anyone actually
>> used it in real code, though. The simplest form, something like:
>>
>> %DECLARE I FIXED;
>> %DO I = 1 TO 10;
>> Z(I)=X(I)+Y(I);
>> %END;
>> %DEACTIVATE I;
>>
>> will expand into 10 assignment statements.

>
> This form of DO statement is not permitted
> (unless it has been implemented in later versions of
> VA PL/I).


On the contrary, it has been supported in every IBM PL/I compiler except
the D compiler (which didn't have a preprocessor at all, except for my
patched version with the %INCLUDE statement).

Note, however, that unrolling loops at the source level in this way is
now regarded as dubious practice. Between modern compilers and funky
modern hardware, it's usually better to let the optimizer do its thing.
--
John W. Kennedy
"The poor have sometimes objected to being governed badly; the rich have
always objected to being governed at all."
-- G. K. Chesterton. "The Man Who Was Thursday"
Reply With Quote
  #8  
Old 02-02-2008, 02:35 AM
James J. Weinkam
Guest
 
Default Re: Automatically transform or expand do loop in a subroutine

CG wrote:
> On 02/01/08 02:36 pm, glen herrmannsfeldt wrote:
>> robin wrote:
>> (snip, I wrote)
>>
>>>> Loop unrolling was one of the favorite examples of the power
>>>> of the PL/I preprocessor. I don't know that anyone actually
>>>> used it in real code, though. The simplest form, something like:

>>
>>>> %DECLARE I FIXED;
>>>> %DO I = 1 TO 10;
>>>> Z(I)=X(I)+Y(I);
>>>> %END;
>>>> %DEACTIVATE I;

>>
>>>> will expand into 10 assignment statements.

>>
>>> This form of DO statement is not permitted
>>> (unless it has been implemented in later versions of
>>> VA PL/I).

>>
>> That was cut/paste directly from:
>>
>> http://publibfp.boulder.ibm.com/cgi-...ol004/20.1.8.3
>>
>> the same example is in:
>>
>> http://www.bitsavers.org/pdf/ibm/360...gSpc_Jul66.pdf
>>
>> from 1966. Maybe VA removed this feature?

>
> From the Enterprise PL/I V3.7 LRM description of:
>> %DO Statement
> > . . .
>> Note: All the formats of the DO statement are supported except:
>> * UPTHRU and DOWNTHRU are not accepted.
>> * The specification in Type 3 DO statements cannot
>> be specified multiple times.

>
> Carl


According to the manuals I have access to, the F and Optimizing
Compilers only allowed %DO; %END: or %DO index=... TO ... BY ...: %END:
Personal PL/I for OS/2 (which I believe is an early version of VA,
only allows %DO; %END; inline but allows everything but UPTHRU, DOWNTO,
and multiple specification within a preprocessor procedure. The
enterprise compilers are as stated above.
Reply With Quote
  #9  
Old 02-02-2008, 08:23 AM
robin
Guest
 
Default Re: Automatically transform or expand do loop in a subroutine

"John W. Kennedy" <jwkenne@attglobal.net> wrote in message news:47a3f5bc$0$15172$607ed4bc@cv.net...
> robin wrote:
> > "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> > news:JKydnWLn472ouz_anZ2dnUVZ_jqdnZ2d@comcast.com. ..
> >> Gordon Sande wrote:
> >>
> >> (snip)
> >>
> >>> Some compilers have options to unroll loops as part of their stronger
> >>> optimization strategies. Read the compiler documentation carefully.
> >>> This capability is more likely to be present in commercial compilers that
> >>> make a point of providing fast executables. As opposed to being free or
> >>> having good debugging. Some compilers will even inline small user functions
> >>> as part of their stronger optimization. If optimizing were truly important
> >>> for you I would expect that you would have current versions of several
> >>> compilers rather than one which has not been supported for several years.
> >> Loop unrolling was one of the favorite examples of the power
> >> of the PL/I preprocessor. I don't know that anyone actually
> >> used it in real code, though. The simplest form, something like:
> >>
> >> %DECLARE I FIXED;
> >> %DO I = 1 TO 10;
> >> Z(I)=X(I)+Y(I);
> >> %END;
> >> %DEACTIVATE I;
> >>
> >> will expand into 10 assignment statements.

> >
> > This form of DO statement is not permitted
> > (unless it has been implemented in later versions of
> > VA PL/I).

>
> On the contrary, it has been supported in every IBM PL/I compiler except
> the D compiler


This form of DO has not been supported since IBM
introduced PL/I for OS/2 (1994) and derivatives including
IBM's VA compiler.
It may have been re-introduced in a more recent
version, as I intimated.

> (which didn't have a preprocessor at all, except for my
> patched version with the %INCLUDE statement).
>
> Note, however, that unrolling loops at the source level in this way is
> now regarded as dubious practice.


There can be perfectly legitimate reasons for
unrolling at the source level.

One of the advantages is that array subscripts are
often constants, and when compiled, the subscripting
is done at compile time. This is very advantageous
for matrices and multiply-subscripted variables.

> Between modern compilers and funky
> modern hardware, it's usually better to let the optimizer do its thing.



Reply With Quote
  #10  
Old 02-02-2008, 08:23 AM
robin
Guest
 
Default Re: Automatically transform or expand do loop in a subroutine

"CG" <Carl.Gehr.ButNoSPAMStuff5@MCGCG.Com> wrote in message
news:66baf$47a3c1a6$d06620ed$2875@FUSE.NET...
> On 02/01/08 02:36 pm, glen herrmannsfeldt wrote:
> > robin wrote:
> > (snip, I wrote)
> >
> >>> Loop unrolling was one of the favorite examples of the power
> >>> of the PL/I preprocessor. I don't know that anyone actually
> >>> used it in real code, though. The simplest form, something like:

> >
> >>> %DECLARE I FIXED;
> >>> %DO I = 1 TO 10;
> >>> Z(I)=X(I)+Y(I);
> >>> %END;
> >>> %DEACTIVATE I;

> >
> >>> will expand into 10 assignment statements.

> >
> >> This form of DO statement is not permitted
> >> (unless it has been implemented in later versions of
> >> VA PL/I).

> >
> > That was cut/paste directly from:
> >
> > http://publibfp.boulder.ibm.com/cgi-...ol004/20.1.8.3
> >
> > the same example is in:
> >
> > http://www.bitsavers.org/pdf/ibm/360...gSpc_Jul66.pdf
> >
> > from 1966. Maybe VA removed this feature?

>
> From the Enterprise PL/I V3.7 LRM description of:
> > %DO Statement


And Websphere PL/I?


Reply With Quote
Reply


Thread Tools
Display Modes


All times are GMT -5. The time now is 05:17 PM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
vB Ad Management by =RedTyger=

In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.