Any reason why this would fail ?

Hi, All !

Try this:

TEST40 : PROCEDURE OPTIONS(MAIN) ;
DCL I FIXED BIN(15,0) INIT (1);
DCL K PIC '999' INIT (3);
DO I=1 TO (K - 1);
PUT LIST ('HELLO');
END;
PUT LIST('BYE');
END TEST40 ;


Under PL/I for MVS&VM, this prints 'HELLO' twice, and 'BYE' once.

Under PL/I for Windows, 'DO' gets ONCODE=8097.

It seems to be related to "TO" condition being both a pseudo variable
AND "K" being declared as "PICTURE".

I couldn't find any such restriction documented.

Pi-R wrote:
> Hi, All !
>
> Try this:
>
> TEST40 : PROCEDURE OPTIONS(MAIN) ;
> DCL I FIXED BIN(15,0) INIT (1);
> DCL K PIC '999' INIT (3);
> DO I=1 TO (K - 1);
> PUT LIST ('HELLO');
> END;
> PUT LIST('BYE');
> END TEST40 ;
>
>
> Under PL/I for MVS&VM, this prints 'HELLO' twice, and 'BYE' once.
>
> Under PL/I for Windows, 'DO' gets ONCODE=8097.
>
> It seems to be related to "TO" condition being both a pseudo variable

No it isn't.

> AND "K" being declared as "PICTURE".
>
> I couldn't find any such restriction documented.

That's because it's a compiler bug, not a restriction.

On the other hand using a PICTURE in a DO is lousy coding that
/deserves/ to be snarled up by a compiler bug.

--
John W. Kennedy
"Only an idiot fights a war on two fronts. Only the heir to the throne
of the kingdom of idiots would fight a war on twelve fronts"
-- J. Michael Straczynski. "Babylon 5", "Ceremonies of Light and Dark"

John W. Kennedy wrote:

(snip)

> On the other hand using a PICTURE in a DO is lousy coding that
> /deserves/ to be snarled up by a compiler bug.

Using one for the DO variable, where it needs to be converted
two or three times each pass through the loop is bad.
As the TO or BY, not so bad. (I believe they are evaluated
once and a copy is used. Then again, I am not sure what form
the copy is in.)

I have commented here before about using CHAR variables
in DO loops.

-- glen

glen herrmannsfeldt wrote:
> John W. Kennedy wrote:
>
> (snip)
>
>> On the other hand using a PICTURE in a DO is lousy coding that
>> /deserves/ to be snarled up by a compiler bug.
>
> Using one for the DO variable, where it needs to be converted
> two or three times each pass through the loop is bad.

Not so much bad as inefficient.

> As the TO or BY, not so bad. (I believe they are evaluated
> once and a copy is used. Then again, I am not sure what form
> the copy is in.)

This is basically correct. It says so in the LRM under the description
of type3 do statements. The LRM's for current compliers are not as
rigorous as those for the Optimizing or F compilers, so a certain amount
of reading between the lines is needed. Basically the expansion of

s0: do index=exp1 to exp2 by exp3 while(exp4) until(exp5);
body;
s1: end;
next: statement;

is equivalent to the following (where p is a compiler generated pointer,
v is a compiler generated variable based on p having the data type
attributes of index, and e1, e2, and e3 are compiler generated variables
having the attributes of exp1, exp2, and exp3 respectively):

s1: p=addr(index);
e1=exp1; e2=exp2; e3=exp3;
v=e1;
s2: if e3>=0&v>e2|e3<0&v<e2 then go to next;
if exp4 then; else go to next;
body;
s1: if exp5 then go to next;
v=v+e3;
go to s2;
next: statement;

The above is adapted from the optimizing compiler LRM. Current LRM's do
not show line 1 or mention that v is based on p. All manuals say the the
above only applies if index is not a pseudo variable; none of them
explain what happens in that case. In fact, a pseudo variable
accomplishes in a different way exactly the same thing as a based
variable reference as an assignment target, that is is determines a
storage location, an extent, and an encoding scheme to be used for the
assignment of a value. Thus, while it is not possible to express it in
PL/I, when index is a pseudo variable reference the compiler is able to
convert that into a pointer value and a based variable just as in the
case of an ordinary variable reference. In all cases, then, the first
thing is to fix for the duration of the do statement the storage
location and data type of the loop control variable.

It must be borne in mind however that the expansion above defines the
meaning of the type 3 do statement but does not specify the actual code
generated. The optimizer will eliminate redundancy. For example, in many
cases some or all of exp1, exp2, and exp3 are literals or non assignable
objects. In such cases the assignments to e1, e2 or e3 can be dispensed
with, although the relevant values may still be moved to registers
outsid the loop for efficiency. Similarly, the comparison of v to e2 and
the increment v+e3 are both evaluated according to the rules for
expression evaluation. This may require conversion of either or both
operands. Since the value of v changes on each iteration, any required
conversion(s) of v must be done within the loop but any conversion of e2
and/or e3 can be done outside the loop. Also the test is shown at the
top of the loop and there is an unconditional branch at the bottom that
is executed once for each execution of the body (unless the loop in
terminated by the until clause). In fact the optimizer moves the test to
the bottom of the loop and the conditional branch to the top. The test
and conditional branch are executed the same number of times but the
unconditional branch is now executed just once. Moreover separate test
code is generated for the positive and negative cases of e3 and the
determination of the sign is done outside the loop and only the relevant
case executed inside it. If the sign of e3 is known at compile time
only the relevant test code is generated.



>
> I have commented here before about using CHAR variables
> in DO loops.
>
> -- glen
>

"John W. Kennedy" <jwkenne@attglobal.net> wrote in message news:47db31ea$0$25049$607ed4bc@cv.net...
> Pi-R wrote:

> > Try this:
> >
> > TEST40 : PROCEDURE OPTIONS(MAIN) ;
> > DCL I FIXED BIN(15,0) INIT (1);
> > DCL K PIC '999' INIT (3);
> > DO I=1 TO (K - 1);
> > PUT LIST ('HELLO');
> > END;
> > PUT LIST('BYE');
> > END TEST40 ;
>
> > Under PL/I for MVS&VM, this prints 'HELLO' twice, and 'BYE' once.
> > Under PL/I for Windows, 'DO' gets ONCODE=8097.
> > It seems to be related to "TO" condition being both a pseudo variable
> > AND "K" being declared as "PICTURE".
> >
> > I couldn't find any such restriction documented.
>
> That's because it's a compiler bug, not a restriction.
>
> On the other hand using a PICTURE in a DO is lousy coding that
> /deserves/ to be snarled up by a compiler bug.

There's nothing wrong in using K in that DO,
because it's converted only once.

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:yL2dnUwgFaC_lEPanZ2dnUVZ_jKdnZ2d@comcast.com. ..
> John W. Kennedy wrote:
>
> > On the other hand using a PICTURE in a DO is lousy coding that
> > /deserves/ to be snarled up by a compiler bug.
>
> Using one for the DO variable, where it needs to be converted
> two or three times each pass through the loop is bad.

Depends what it is used for. If there is some good reason for
the using it elsewhere in the loop, the gains may outweigh
the losses. The PIC variable will need to be converted to arithmetic
for purposes of incrementing, and back again to PIC.

> As the TO or BY, not so bad. (I believe they are evaluated
> once and a copy is used.

These are evaluated before loop entry, and so are
fixed for the duration of the loop.

> Then again, I am not sure what form
> the copy is in.)

It's in the same form as the control variable.

> I have commented here before about using CHAR variables
> in DO loops.

That's irrelevant.

"Pi-R" <pierre@berrigan.org> wrote in message
news:59e532d1-b689-46cf-9729-9ae6868c1bf1@n77g2000hse.googlegroups.com...

> Try this:
>
> TEST40 : PROCEDURE OPTIONS(MAIN) ;
> DCL I FIXED BIN(15,0) INIT (1);
> DCL K PIC '999' INIT (3);
> DO I=1 TO (K - 1);
> PUT LIST ('HELLO');
> END;
> PUT LIST('BYE');
> END TEST40 ;
>
>
> Under PL/I for MVS&VM, this prints 'HELLO' twice, and 'BYE' once.
>
> Under PL/I for Windows, 'DO' gets ONCODE=8097.

It would have to be an introduced bug, for it works in early versions.

John W. Kennedy wrote:
> Pi-R wrote:
>> Hi, All !
>>
>> Try this:
>>
>> TEST40 : PROCEDURE OPTIONS(MAIN) ;
>> DCL I FIXED BIN(15,0) INIT (1);
>> DCL K PIC '999' INIT (3);
>> DO I=1 TO (K - 1);
>> PUT LIST ('HELLO');
>> END;
>> PUT LIST('BYE');
>> END TEST40 ;
>>
>>
>> Under PL/I for MVS&VM, this prints 'HELLO' twice, and 'BYE' once.
>>
>> Under PL/I for Windows, 'DO' gets ONCODE=8097.
>>
>> It seems to be related to "TO" condition being both a pseudo variable
>
> No it isn't.
>
>> AND "K" being declared as "PICTURE".
>>
>> I couldn't find any such restriction documented.
>
> That's because it's a compiler bug, not a restriction.
>
> On the other hand using a PICTURE in a DO is lousy coding that
> /deserves/ to be snarled up by a compiler bug.
>
I can't believe you really mean this. If the source is legal PL/I the
compiler should generate code that does what the language definition
specifies in the most efficient way it can.

On the other hand, if through ignorance or incompetence the programmer
does something stupid and gets unexpected results, he does indeed get
what he deserves.

I admit that I can't imagine myself ever wanting to use a numeric
character variable as in this example, but if ever I came upon a good
reason for wanting to do so and it didn't work I'd be pretty annoyed.

James J. Weinkam wrote:

(snip)

> The above is adapted from the optimizing compiler LRM. Current LRM's do
> not show line 1 or mention that v is based on p. All manuals say the the
> above only applies if index is not a pseudo variable; none of them
> explain what happens in that case. In fact, a pseudo variable
> accomplishes in a different way exactly the same thing as a based
> variable reference as an assignment target, that is is determines a
> storage location, an extent, and an encoding scheme to be used for the
> assignment of a value. Thus, while it is not possible to express it in
> PL/I, when index is a pseudo variable reference the compiler is able to
> convert that into a pointer value and a based variable just as in the
> case of an ordinary variable reference. In all cases, then, the first
> thing is to fix for the duration of the do statement the storage
> location and data type of the loop control variable.

The only one I ever tried was IMAG(), which worked. I always thought
that it used both the IMAG pseudo-variable and function to do it, but
it could be a pointer as you say. Though I believe the one I tried it
in didn't have pointers. (CALL/OS PL/I, much less than PL/I (F)).

DCL X COMPLEX FLOAT BIN(53);
X=0;
DO IMAG(X)=1 TO 100;
PUT SKIP LIST(SQRT(X));
END;

Are there pseudo-variables that do conversions that a pointer
couldn't compensate for?

DO SUBSTR(C,10,10)=' 1' TO ' 100';

-- glen

glen herrmannsfeldt wrote:
> James J. Weinkam wrote:
>
> (snip)
>
>> The above is adapted from the optimizing compiler LRM. Current LRM's
>> do not show line 1 or mention that v is based on p. All manuals say
>> the the above only applies if index is not a pseudo variable; none of
>> them explain what happens in that case. In fact, a pseudo variable
>> accomplishes in a different way exactly the same thing as a based
>> variable reference as an assignment target, that is is determines a
>> storage location, an extent, and an encoding scheme to be used for the
>> assignment of a value. Thus, while it is not possible to express it in
>> PL/I, when index is a pseudo variable reference the compiler is able
>> to convert that into a pointer value and a based variable just as in
>> the case of an ordinary variable reference. In all cases, then, the
>> first thing is to fix for the duration of the do statement the storage
>> location and data type of the loop control variable.
>
> The only one I ever tried was IMAG(), which worked. I always thought
> that it used both the IMAG pseudo-variable and function to do it, but
> it could be a pointer as you say. Though I believe the one I tried it
> in didn't have pointers. (CALL/OS PL/I, much less than PL/I (F)).

PL/I-F did have pointers, but that isn't the point. The code shown is
just a means of explaining the semantics rigorously. The compiler is
free to do something quite different under the covers as long as it
achieves equivalent behavior.

>
> DCL X COMPLEX FLOAT BIN(53);
> X=0;
> DO IMAG(X)=1 TO 100;
> PUT SKIP LIST(SQRT(X));
> END;
>
> Are there pseudo-variables that do conversions that a pointer
> couldn't compensate for?
>
> DO SUBSTR(C,10,10)=' 1' TO ' 100';
>
> -- glen
>
The only pseudo variables that can be used in this context are substr,
unspec, real, and imag.