On Tuesday, October 27, 2020 at 8:26:38 PM UTC+11, Peter J. Seymour wrote:

I find the syntax with multiple DO groups a bit alarming. The problem in
this case is the multiple DO groups. If you remove the 1 TO 26 group so reducing things to a single group, and recode it as a loop around the
PUT statement, the results seem correct.

.
There's nothing intimidating or alarming about that PUT statement.
The EDIT list occupies less than half a line, and is quite clear.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, October 30, 2020 at 2:41:12 AM UTC+11, c......@gmail.com wrote:

El miércoles, 28 de octubre de 2020 a la(s) 22:20:21 UTC-3, Robin Vowels escribió:

On Thursday, October 29, 2020 at 3:19:41 AM UTC+11, c......@gmail.com wrote:

Hi Everyone,

Hi Robin!,

In the compiler version I used I've got a conversion error during runtime, that's why I changed the format. Actually there are some differences in PL/I Subset D, (f) and optimizing, reflecting the development of the software and computer capacity along

years.

PLI(f) was able to run, in computers so tiny, we would consider them a joke.

I agree PL/I is very permisive in the use of identifiers, and not declaring them, but this is also a nice way, to get hard to find bugs ( for instance the overflows, were caused by endings in 0 and O. or L and I or 1.

As for myself I would have declared all the variables, commenting out them, a way I use since my first PLI in the 1970's. This, along the options, nest, xref and nest and (check:) are wonderful debugging tools, from a time where you had to debug based

in assembly code, and memory dumps.

I would have modularizated the program, with internal modules, and also would have simplified all the formats.
Seems like the then candidate to doctorate, was influenced by FORTRAN IV style, very much used in universities, during 1960's and 70's

And why translate to C++ ? Because mr Kumaresh is doctorate candidate, doing original work, using as a tool flow model systems based in C++. Having this programs up and running, can help him to veryfy his results. This original thesis from the 1970's

was test using PL/I under CMS. Now half a century later, there are other tools.

Regard,
Carlos

.
Back in 1966, PL/I took the default rule for names
from FORTRAN, along with the facility to avoid
explicit declarations for names.
That was helpful, because most people had limted typing skills.
For years now, it has been possible to force all variables
to be declared explicitly.
.
As for IBM PL/I subset D, that was intended for small
machines having limited core memory.
.
IBM's PL/I-F compler was intended for modest to large
machines, from 64K core memory and above. It implemented
pretty well all the language.
.
IBM's PL/I Optimising and Checkout compilers introduced a few
extra features relevant to structured programming,
including DO FOREVER; LEAVE and ITERATE.
.
Major enhancements occurred with IBM's PL/I for OS/2 in 1994.
They included many character-handling built-in functions,
and many numeric built-in functions including a random number
generator.
.
There's no need to translate that PL/I program to C++.
You say, "half a century later, there are other tools".
But just because the name of the language has not changed
does not mean that no improvements have been made to the
language. In effect, PL/I has become PL/I++.
It is just as modern and useful as it ever was.

p.s., Thanks for getting the PL/I program to work.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El viernes, 30 de octubre de 2020 a la(s) 07:17:06 UTC-3, Robin Vowels escribió:

On Friday, October 30, 2020 at 2:41:12 AM UTC+11, c......@gmail.com wrote:

El miércoles, 28 de octubre de 2020 a la(s) 22:20:21 UTC-3, Robin Vowels escribió:

On Thursday, October 29, 2020 at 3:19:41 AM UTC+11, c......@gmail.com wrote:

Hi Everyone,

Hi Robin!,

In the compiler version I used I've got a conversion error during runtime, that's why I changed the format. Actually there are some differences in PL/I Subset D, (f) and optimizing, reflecting the development of the software and computer capacity

along years.

PLI(f) was able to run, in computers so tiny, we would consider them a joke.

I agree PL/I is very permisive in the use of identifiers, and not declaring them, but this is also a nice way, to get hard to find bugs ( for instance the overflows, were caused by endings in 0 and O. or L and I or 1.

As for myself I would have declared all the variables, commenting out them, a way I use since my first PLI in the 1970's. This, along the options, nest, xref and nest and (check:) are wonderful debugging tools, from a time where you had to debug

based in assembly code, and memory dumps.

I would have modularizated the program, with internal modules, and also would have simplified all the formats.
Seems like the then candidate to doctorate, was influenced by FORTRAN IV style, very much used in universities, during 1960's and 70's

And why translate to C++ ? Because mr Kumaresh is doctorate candidate, doing original work, using as a tool flow model systems based in C++. Having this programs up and running, can help him to veryfy his results. This original thesis from the 1970's

was test using PL/I under CMS. Now half a century later, there are other tools.

Regard,
Carlos

.
Back in 1966, PL/I took the default rule for names
from FORTRAN, along with the facility to avoid
explicit declarations for names.
That was helpful, because most people had limted typing skills.
For years now, it has been possible to force all variables
to be declared explicitly.
.
As for IBM PL/I subset D, that was intended for small
machines having limited core memory.
.
IBM's PL/I-F compler was intended for modest to large
machines, from 64K core memory and above. It implemented
pretty well all the language.
.
IBM's PL/I Optimising and Checkout compilers introduced a few
extra features relevant to structured programming,
including DO FOREVER; LEAVE and ITERATE.
.
Major enhancements occurred with IBM's PL/I for OS/2 in 1994.
They included many character-handling built-in functions,
and many numeric built-in functions including a random number
generator.
.
There's no need to translate that PL/I program to C++.
You say, "half a century later, there are other tools".
But just because the name of the language has not changed
does not mean that no improvements have been made to the
language. In effect, PL/I has become PL/I++.
It is just as modern and useful as it ever was.

p.s., Thanks for getting the PL/I program to work.

Well, this thesis on combustion models, was done with the more advanced equpment of it's time, IBM/370, CMS, PLI.But at the time computers were really slow, and with very few memory ( a fortran finite differential equations, took me 15 minutes of CPU
time ) only batch processing, and the only "plotter" available was 1403 chain printer.

Now you have wonderful tools, even direct connection to your experiment sensor network. This gentleman, has to write a model, in a modern sytem called Open Foam, which accepts C++ modules.

Sorry about, the "modern" language, I'm out of the mainframe world, since I used for the last time an IBM/370 in 1980.
I would have loved to use PL/I in my daily work with realtime systems, but there's no PL/I available for microcontrollers. Last version was INTEL's and Gary Tildall PL/M, almost 40! years ago.

I'm not very impressed with object oriented programming, Most of their concepts, were implemented in PL/I(f) , we had multiple entries for procedures. Internal procedures, are pretty much like classes, we had static and dynamic data storage, even
structures and arrays could be dynamically allocated.

That was a real advance from a time when computers, where card and tape feed, to crunch numbers, or manage HUGE, finantial data.

At the time of PL/I developement, IBM was very jealous of their OS, so you need to be a super user, with OS privileges, to access, I/O Channels, or memmory, so you have to write assembly or use the forbidden tool PL/C if you want to write hardware
drivers. IBM at the time stated: USERS ONLY RUN BATCH ( even CMS is a sort of specialized batch machine ).
Today we can program FOR FREE, in a 32 bit microcomputer, using a realtime preemptive multitasking OS, device drivers, user interfases , Fast Fourier Transform, Networking, Input and output, several datacommunication protocols, etc.
Of course I prefer UNIX or Linux, over Windows. But in my area, Microsoft just made tabula rasa, and there's no OS/2 systems ( last one I used was 1994 ) and very few Unixes ( Some Qnxs and may be some linuxes, for non critical applications ).

best regards
Carlos

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I'm not very impressed with object oriented programming, Most of their concepts, were implemented in PL/I(f) , we had multiple entries for procedures. Internal procedures, are pretty much like classes, we had static and dynamic data storage, even

structures and arrays could be dynamically allocated.

...

best regards
Carlos

Carlos, you forgot that PL/I could be compiled to pseudo code, similar to a machine code. One could write an interpreter on any machine to read the pseudo code and execute the local machine's machine code. Just as is done with the JVM (Java Virtual
Machine). Which is to say that PL/I was write once, run anywhere. It was way ahead of Java. Unfortunately, IBM considered themselves a hardware company and didn't push their software.

Cornel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine
was The PL/I Checkout Compiler, and it didn't target anything but the then-current IBM 360 OS. PL/I was never write once, run anywhere.

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

Anyone who thinks PL/I was more advanced than Java doesn't know anything
about PL/I or Java.

Carlos, you forgot that PL/I could be compiled to pseudo code, similar to a machine code. One could write an interpreter on any machine to read the pseudo code and execute the local machine's machine code. Just as is done with the JVM (Java Virtual

Machine). Which is to say that PL/I was write once, run anywhere. It was way ahead of Java. Unfortunately, IBM considered themselves a hardware company and didn't push their software.

Cornel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, November 1, 2020 at 3:51:40 AM UTC-5, Eric Jackson wrote:

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine
was The PL/I Checkout Compiler, and it didn't target anything but the then-current IBM 360 OS. PL/I was never write once, run anywhere.

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

I know what pseudo code means now. And I know that back in the 70's, one of the optional outputs from a PL/I compiler was called pseudo code. And I know that is was like a machine code and one could write an interpreter for it, though I'm not aware
that anyone did.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/1/20 1:52 PM, Cornell Sternbergh wrote:

On Sunday, November 1, 2020 at 3:51:40 AM UTC-5, Eric Jackson wrote:

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine
was The PL/I Checkout Compiler, and it didn't target anything but the
then-current IBM 360 OS. PL/I was never write once, run anywhere.

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

I know what pseudo code means now. And I know that back in the 70's, one of the optional outputs from a PL/I compiler was called pseudo code. And I know that is was like a machine code and one could write an interpreter for it, though I'm not aware

that anyone did.

I believe you are thinking of Pseudo-Assembler Code, a printed hex representation of the object code produced by the compiler, annotated
with an approximation of assembler language that might produce it.
Something of the sort has been standard in IBM compilers for many
decades, though more modern systms generally rely on the ability of
symbolic debuggers to display code as it runs.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, November 1, 2020 at 7:51:40 PM UTC+11, Eric Jackson wrote:

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine
was The PL/I Checkout Compiler, and it didn't target anything but the then-current IBM 360 OS. PL/I was never write once, run anywhere.

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

.
PL/C was a serious PL/I compiler. Yes, though it was intended for student use, it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added about 45 seconds to the compile-link-go sequence.
.

Anyone who thinks PL/I was more advanced than Java doesn't know anything about PL/I or Java.

.
PL/I came out a long time before Java.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, November 1, 2020 at 7:51:40 PM UTC+11, Eric Jackson wrote:

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

.

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine
was The PL/I Checkout Compiler, and it didn't target anything but the then-current IBM 360 OS. PL/I was never write once, run anywhere.

.
PL/I has pretty well been "write once, run anywhere".
Additions to the language have not affected the running of existing programs.
.

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

.
PL/C was a serious PL/I compiler. Yes, though it was intended for student use, it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added about 45 seconds to the compile-link-go sequence.
.
Compilation and execution of a PL/I program via PL/C could be over in less time than the compile-link-go of the IBM sofware.
.
Execution time of a PL/C program was slower than that of PL/I-F,
but that didn't matter for short running programs.
.
One special advantage of PL/C was its ability to take a program to
execution, because it was a correcting compiler -- far more than
PL/I-F was.
.
PL/C was to PL/I like WATFOR was to FORTRAN -- a fast compiler
that could get the jobs through in a short time.
.

Anyone who thinks PL/I was more advanced than Java doesn't know anything about PL/I or Java.

.
PL/I came out a long time before Java.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/1/20 10:55 PM, Robin Vowels wrote:

On Sunday, November 1, 2020 at 7:51:40 PM UTC+11, Eric Jackson wrote:

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

..

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine
was The PL/I Checkout Compiler, and it didn't target anything but the
then-current IBM 360 OS. PL/I was never write once, run anywhere.

..
PL/I has pretty well been "write once, run anywhere".

Write once, compile anywhere, as opposed to Java’s compile once, run anywhere.

Additions to the language have not affected the running of existing programs. ..

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

..
PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added about 45 seconds to the compile-link-go sequence.

Which is why the load-and-go program was developed as an alternative.

..
Compilation and execution of a PL/I program via PL/C could be over in less time
than the compile-link-go of the IBM sofware.
..
Execution time of a PL/C program was slower than that of PL/I-F,
but that didn't matter for short running programs.
..
One special advantage of PL/C was its ability to take a program to
execution, because it was a correcting compiler -- far more than
PL/I-F was.
..
PL/C was to PL/I like WATFOR was to FORTRAN -- a fast compiler
that could get the jobs through in a short time.
..

Anyone who thinks PL/I was more advanced than Java doesn't know anything
about PL/I or Java.

..
PL/I came out a long time before Java.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/1/20 4:46 PM, John W Kennedy wrote:

On 11/1/20 1:52 PM, Cornell Sternbergh wrote:

On Sunday, November 1, 2020 at 3:51:40 AM UTC-5, Eric Jackson wrote:

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine
was The PL/I Checkout Compiler, and it didn't target anything but the
then-current IBM 360 OS. PL/I was never write once, run anywhere.

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

I know what pseudo code means now.  And I know that back in the 70's,
one of the optional outputs from a PL/I compiler was called pseudo
code.  And I know that is was like a machine code and one could write
an interpreter for it, though I'm not aware that anyone did.

I believe you are thinking of Pseudo-Assembler Code, a printed hex representation of the object code produced by the compiler, annotated
with an approximation of assembler language that might produce it.
Something of the sort has been standard in IBM compilers for many
decades, though more modern systms generally rely on the ability of
symbolic debuggers to display code as it runs.

Iron Spring PL/I does this. That was how the compiler was originally
ported from zOS to OS/2 and Linux. In addition to the listing, one of
the options is to generate the assembler file in a format the assembler accepts. I'm not sure this is actually able to be assembled any more,
since it's been years since I had to use it.

The assembly code listing is quite useful for debugging.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, November 1, 2020 at 6:46:36 PM UTC-5, John W. Kennedy wrote:

I know what pseudo code means now. And I know that back in the 70's, one of the optional outputs from a PL/I compiler was called pseudo code. And I know that is was like a machine code and one could write an interpreter for it, though I'm not aware

that anyone did.

I believe you are thinking of Pseudo-Assembler Code, a printed hex representation of the object code produced by the compiler, annotated
with an approximation of assembler language that might produce it.
Something of the sort has been standard in IBM compilers for many
decades, though more modern systms generally rely on the ability of
symbolic debuggers to display code as it runs.
--

Nope... the assembler/machine code output (it was kind of like machine code, but with some names and stuff to make it easier to read, not quite assembler like) from PL/I was the same kind of output one could get from CoBOL or ForTran, it was needed for
dump-reading, the primary debugging method back then. This pseudo code wasn't 360 assembler or machine code, or machine code for any existing hardware. But it was easily (sort of) read by an interpreter which would then execute the local machine's
machine code. But again, I'm not aware anyone ever wrote a virtual machine, i.e. interpreter, for it. IBM figured they were a hardware company and didn't push their software.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/2/20 10:07 AM, John W Kennedy wrote:

On 11/1/20 10:55 PM, Robin Vowels wrote:

On Sunday, November 1, 2020 at 7:51:40 PM UTC+11, Eric Jackson wrote:

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

..

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine
was The PL/I Checkout Compiler, and it didn't target anything but the
then-current IBM 360 OS. PL/I was never write once, run anywhere.

..
PL/I has pretty well been "write once, run anywhere".

Write once, compile anywhere, as opposed to Java’s compile once, run anywhere.

Additions to the language have not affected the running of existing
programs.
..

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

..
PL/C was a serious PL/I compiler. Yes, though it was intended for
student use,
it was also intended for general use, because it was so much faster at
compilation
than PL/I-F. The weakness of the IBM offering was the link editor that
added
about 45 seconds to the compile-link-go sequence.

Which is why the load-and-go program was developed as an alternative.

..
Compilation and execution of a PL/I program via PL/C could be over in
less time
than the compile-link-go of the IBM sofware.
..
Execution time of a PL/C program was slower than that of PL/I-F,
but that didn't matter for short running programs.
..
One special advantage of PL/C was its ability to take a program to
execution, because it was a correcting compiler -- far more than
PL/I-F was.
..
PL/C was to PL/I like WATFOR was to FORTRAN -- a fast compiler
that could get the jobs through in a short time.
..

Anyone who thinks PL/I was more advanced than Java doesn't know anything >>> about PL/I or Java.

..
PL/I came out a long time before Java.

PLUM for the UNIVAC 1108 was the same. I _think_ I do have the source
for PLUM, if anyone has any use for an 1108 assembler program.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/2/20 4:06 PM, Iron Spring Software wrote:

On 11/1/20 4:46 PM, John W Kennedy wrote:

On 11/1/20 1:52 PM, Cornell Sternbergh wrote:

On Sunday, November 1, 2020 at 3:51:40 AM UTC-5, Eric Jackson wrote:

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine >>>> was The PL/I Checkout Compiler, and it didn't target anything but the
then-current IBM 360 OS. PL/I was never write once, run anywhere.

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

I know what pseudo code means now.  And I know that back in the 70's,
one of the optional outputs from a PL/I compiler was called pseudo
code.  And I know that is was like a machine code and one could write
an interpreter for it, though I'm not aware that anyone did.

I believe you are thinking of Pseudo-Assembler Code, a printed hex
representation of the object code produced by the compiler, annotated
with an approximation of assembler language that might produce it.
Something of the sort has been standard in IBM compilers for many
decades, though more modern systms generally rely on the ability of
symbolic debuggers to display code as it runs.

Iron Spring PL/I does this. That was how the compiler was originally
ported from zOS to OS/2 and Linux. In addition to the listing, one of
the options is to generate the assembler file in a format the assembler accepts. I'm not sure this is actually able to be assembled any more,
since it's been years since I had to use it.

The assembly code listing is quite useful for debugging.

Pre-360 IBM compilers generally produced assembler source code instead
of machine code, but the 360 compilers went directly to object code, and
it was quickly noticed that 360 compilers were actually faster than 360 assemblers were for equivalent programs (probably because of the huge
system macros needed to write normal 360 programs), which led to the
360’s huge jump in use of compilers (apart from FORTRAN, which had
always been popular). Most of them could print assembler-like listings,
but some just did hex dumps of the code, and none of the 360 compilers
produced source-code assembler that could actually be assembled.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/2/2020 1:07 PM, Cornell Sternbergh wrote:

Nope... the assembler/machine code output (it was kind of like machine code, but with some names and stuff to make it easier to read, not quite assembler like) from PL/I was the same kind of output one could get from CoBOL or ForTran, it was needed for

dump-reading, the primary debugging method back then. This pseudo code wasn't 360 assembler or machine code, or machine code for any existing hardware. But it was easily (sort of) read by an interpreter which would then execute the local machine's
machine code. But again, I'm not aware anyone ever wrote a virtual machine, i.e. interpreter, for it. IBM figured they were a hardware company and didn't push their software.


You remain very confused. Pseudo code and the pseudo-assembly listing
are two completely different things. The PL/I-F and PL/I Optimizing
compilers compiled into object code with no intermediate human-readable
output; there was an intermediate encoding, called "triples" in the PLM,
but it wasn't the pseudo-assembly listing produced by the "list" option.
The object code generation phase produced object code directly from
the triples without any intermediate assembly being produced.

The pseudo-assembly listing wasn't machine independent at all; it was a representation of the generated 360 object code and was only a listing
created for the programmer to aid debugging. There was no interpreter
to run it and it didn't wasn't used for anything by the during
compilation, linking or at run time.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/2/20 4:07 PM, Cornell Sternbergh wrote:

On Sunday, November 1, 2020 at 6:46:36 PM UTC-5, John W. Kennedy wrote:

I know what pseudo code means now. And I know that back in the 70's, one of the optional outputs from a PL/I compiler was called pseudo code. And I know that is was like a machine code and one could write an interpreter for it, though I'm not aware

that anyone did.

I believe you are thinking of Pseudo-Assembler Code, a printed hex
representation of the object code produced by the compiler, annotated
with an approximation of assembler language that might produce it.
Something of the sort has been standard in IBM compilers for many
decades, though more modern systms generally rely on the ability of
symbolic debuggers to display code as it runs.
--

Nope... the assembler/machine code output (it was kind of like machine code, but with some names and stuff to make it easier to read, not quite assembler like) from PL/I was the same kind of output one could get from CoBOL or ForTran, it was needed for

dump-reading, the primary debugging method back then. This pseudo code wasn't 360 assembler or machine code, or machine code for any existing hardware. But it was easily (sort of) read by an interpreter which would then execute the local machine's
machine code. But again, I'm not aware anyone ever wrote a virtual machine, i.e. interpreter, for it. IBM figured they were a hardware company and didn't push their software.


The listings were not in a format that could be read by any assembler
program, but they represent, opcode-for-opcode, the actual 360 or 370
binary.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/1/2020 7:55 PM, Robin Vowels wrote:

PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added about 45 seconds to the compile-link-go sequence.

Most often serious programs were compiled a few times and then run many
times. Student programs are compiled until the student hopes the errors
are gone and never run again.

Nobody used PL/C for serious commercial or scientific work. It never
had extended floating point, the macro facility nor the fixed decimal
data type.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, November 3, 2020 at 4:07:14 AM UTC+11, John W. Kennedy wrote:

On 11/1/20 10:55 PM, Robin Vowels wrote:

On Sunday, November 1, 2020 at 7:51:40 PM UTC+11, Eric Jackson wrote:

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

..

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine >> was The PL/I Checkout Compiler, and it didn't target anything but the
then-current IBM 360 OS. PL/I was never write once, run anywhere.

..
PL/I has pretty well been "write once, run anywhere".

Write once, compile anywhere, as opposed to Java’s compile once, run anywhere.

Additions to the language have not affected the running of existing programs.
..

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

..
PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added
about 45 seconds to the compile-link-go sequence.

.

Which is why the load-and-go program was developed as an alternative.

.
IBM didn't invent load-and-go, nor PL/C, nor Watfor.
.
Load and go was developed in 1957 by Charles Hamblin -- for GEORGE.
.
Perhaps it was invented even earlier than that.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, November 3, 2020 at 8:07:55 AM UTC+11, Cornell Sternbergh wrote:

On Sunday, November 1, 2020 at 6:46:36 PM UTC-5, John W. Kennedy wrote:

I know what pseudo code means now. And I know that back in the 70's, one of the optional outputs from a PL/I compiler was called pseudo code. And I know that is was like a machine code and one could write an interpreter for it, though I'm not aware

that anyone did.

I believe you are thinking of Pseudo-Assembler Code, a printed hex representation of the object code produced by the compiler, annotated
with an approximation of assembler language that might produce it. Something of the sort has been standard in IBM compilers for many
decades, though more modern systms generally rely on the ability of symbolic debuggers to display code as it runs.
--

Nope... the assembler/machine code output (it was kind of like machine code, but with some names and stuff to make it easier to read, not quite assembler like) from PL/I was the same kind of output one could get from CoBOL or ForTran, it was needed for

dump-reading, the primary debugging method back then.

The assembler code might have been needed for COBOL and FORTRAN,
but it was not needed for PL/I --- PL/I came with its own debugging tools, including CHECK, STMT compiler option(s), and ON conditions for dealing
with computational conditions such as division by zero, SUBSCRIPTRANGE, STRINGRANGE, OVERFLOW, etc etc.

This pseudo code wasn't 360 assembler or machine code, or machine code for any existing hardware. But it was easily (sort of) read by an interpreter which would then execute the local machine's machine code. But again, I'm not aware anyone ever wrote a

virtual machine, i.e. interpreter, for it. IBM figured they were a hardware company and didn't push their software.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, November 3, 2020 at 12:49:43 PM UTC+11, Eric Jackson wrote:

On 11/1/2020 7:55 PM, Robin Vowels wrote:

PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added
about 45 seconds to the compile-link-go sequence.

.

Most often serious programs were compiled a few times

.
Probably many times, especially for large projects.
.

and then run many
times. Student programs are compiled until the student hopes the errors
are gone and never run again.

.

Nobody used PL/C for serious commercial or scientific work.

.
Really!?! Tucker did, and probably many others.
.

It never had extended floating point,

.
Nor did the machine.
.

the macro facility

.
Not everyone needs it.
.

nor the fixed decimal data type.

.
FIXED DECIMAL was available, but compiled to use floating-point instructions.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Eric Jackson <jhril@ca.rr.com> wrote:

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine
was The PL/I Checkout Compiler, and it didn't target anything but the then-current IBM 360 OS. PL/I was never write once, run anywhere.

Not major, but I think there was a machine whose microcoded instruction set
was intended to be a direct analog of PL/I.

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

Anyone who thinks PL/I was more advanced than Java doesn't know anything about PL/I or Java.

Carlos, you forgot that PL/I could be compiled to pseudo code, similar
to a machine code. One could write an interpreter on any machine to
read the pseudo code and execute the local machine's machine code. Just
as is done with the JVM (Java Virtual Machine). Which is to say that
PL/I was write once, run anywhere. It was way ahead of Java.
Unfortunately, IBM considered themselves a hardware company and didn't
push their software.

Cornel

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Cornell Sternbergh <cornell.sternbergh@gmail.com> wrote:

I'm not very impressed with object oriented programming, Most of their
concepts, were implemented in PL/I(f) , we had multiple entries for
procedures. Internal procedures, are pretty much like classes, we had
static and dynamic data storage, even structures and arrays could be
dynamically allocated.

...

best regards
Carlos

Carlos, you forgot that PL/I could be compiled to pseudo code, similar to
a machine code. One could write an interpreter on any machine to read
the pseudo code and execute the local machine's machine code. Just as is done with the JVM (Java Virtual Machine). Which is to say that PL/I was write once, run anywhere. It was way ahead of Java. Unfortunately, IBM considered themselves a hardware company and didn't push their software.

I’m having fun now working on the preprocessor. I compiler preprocessor statements to intermediate code, and then interpret that to do the actual preprocessing.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, November 3, 2020 at 7:22:27 AM UTC-5, Robin Vowels wrote:

On Tuesday, November 3, 2020 at 12:49:43 PM UTC+11, Eric Jackson wrote:

On 11/1/2020 7:55 PM, Robin Vowels wrote:

PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added
about 45 seconds to the compile-link-go sequence.

.

Most often serious programs were compiled a few times

.
Probably many times, especially for large projects.
.

and then run many
times. Student programs are compiled until the student hopes the errors are gone and never run again.

.

Nobody used PL/C for serious commercial or scientific work.

.
Really!?! Tucker did, and probably many others.
.

It never had extended floating point,

.
Nor did the machine.
.

the macro facility

.
Not everyone needs it.
.

nor the fixed decimal data type.

.
FIXED DECIMAL was available, but compiled to use floating-point instructions.

My PL/C memories...

- At the university I attended it was heavily used, from the 101 classes on up as it was free, offered the ability to do structured programming at a time before decent and inexpensive Pascal compilers became available and used a lot less CPU time for
compilation and fewer surprises with arithmetic than IBM’s compilers.

- It was said the main deficiently of PL/C was that it didn’t support BASED variables. The IBM checkout compiler did but it was expensive. Pascal did, so for this reason and many others Pascal replaced PL/C at my institution.

- I never looked closely at the code generated by PL/C, but I had it on good authority all the code did was to build parameter lists and call internal library routines, no matter how simple the operation was. So in a way the code resembled pcode.

- PL/C was a one pass compiler. It had a lot of trouble (would crash) with large programs with a lot of forward procedure references, especially if the parameters to the procedures required type conversion, or if a function returned something other than
fixed binary or float. Apparently if the formal parameter type or function return type were unknown (forward) it would make a guess and later back patch as necessary when the procedure source was encountered. Usually you had to rearrange your source code
to eliminate the forward references. For forward function references you could add a "hint declaration" for example “DCL FUNC(X,Y,Z) INTERNAL RETURNS (CHAR(1))” and this often gave enough info to the compiler to stop the crashes.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/3/20 7:04 AM, Robin Vowels wrote:

On Tuesday, November 3, 2020 at 4:07:14 AM UTC+11, John W. Kennedy wrote:

On 11/1/20 10:55 PM, Robin Vowels wrote:

On Sunday, November 1, 2020 at 7:51:40 PM UTC+11, Eric Jackson wrote:

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

..

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine >>>> was The PL/I Checkout Compiler, and it didn't target anything but the
then-current IBM 360 OS. PL/I was never write once, run anywhere.

..
PL/I has pretty well been "write once, run anywhere".

Write once, compile anywhere, as opposed to Java’s compile once, run
anywhere.

Additions to the language have not affected the running of existing programs.
..

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

..
PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added
about 45 seconds to the compile-link-go sequence.

..

Which is why the load-and-go program was developed as an alternative.

..
IBM didn't invent load-and-go, nor PL/C, nor Watfor.
..
Load and go was developed in 1957 by Charles Hamblin -- for GEORGE.
..
Perhaps it was invented even earlier than that.

I said “developed”, not “invented”.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/3/20 12:49 PM, Peter Flass wrote:

Eric Jackson <jhril@ca.rr.com> wrote:

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine
was The PL/I Checkout Compiler, and it didn't target anything but the
then-current IBM 360 OS. PL/I was never write once, run anywhere.

Not major, but I think there was a machine whose microcoded instruction set was intended to be a direct analog of PL/I.

The Allen-Babcock RUSH time=sharing system used a 360/50 with funky PL/I-oriented ROM.

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

Anyone who thinks PL/I was more advanced than Java doesn't know anything
about PL/I or Java.

Carlos, you forgot that PL/I could be compiled to pseudo code, similar
to a machine code. One could write an interpreter on any machine to
read the pseudo code and execute the local machine's machine code. Just >>> as is done with the JVM (Java Virtual Machine). Which is to say that
PL/I was write once, run anywhere. It was way ahead of Java.
Unfortunately, IBM considered themselves a hardware company and didn't
push their software.

Cornel

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/3/2020 9:49 AM, Peter Flass wrote:

Not major, but I think there was a machine whose microcoded instruction set was intended to be a direct analog of PL/I.

Which would be pretty much the opposite of "write once, run everywhere".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, November 3, 2020 at 12:49:51 PM UTC-5, bearlyabus...@gmail.com wrote:

Cornell Sternbergh <cornell.s...@gmail.com> wrote:

I'm not very impressed with object oriented programming, Most of their
concepts, were implemented in PL/I(f) , we had multiple entries for
procedures. Internal procedures, are pretty much like classes, we had
static and dynamic data storage, even structures and arrays could be
dynamically allocated.

...

best regards
Carlos

Carlos, you forgot that PL/I could be compiled to pseudo code, similar to a machine code. One could write an interpreter on any machine to read
the pseudo code and execute the local machine's machine code. Just as is done with the JVM (Java Virtual Machine). Which is to say that PL/I was write once, run anywhere. It was way ahead of Java. Unfortunately, IBM considered themselves a hardware company and didn't push their software.

I’m having fun now working on the preprocessor. I compiler preprocessor statements to intermediate code, and then interpret that to do the actual preprocessing.

--
Pete

A bit off-topic, but... fond memories... The preprocessor can be lots of fun. It basically used PL/I syntax on strings in the code, and generated strings which would then be consumed as PL/I statements by the compiler. One of the few things I miss
about CoBOL is the DATE-COMPILED special register. One could set a variable to that value and then print the variable and show the compile date/time, and hence the version, of the program. I created a PL/I preprocessor function that would return the
current date/time as a string, i.e. simulated the DATE-COMPILED special register.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/3/20 11:31 PM, Eric Jackson wrote:

On 11/3/2020 9:49 AM, Peter Flass wrote:

Not major, but I think there was a machine whose microcoded
instruction set
was intended to be a direct analog of PL/I.

Which would be pretty much the opposite of "write once, run everywhere".

Not at all. “Write once, run everywhere” demands only that the source
code be compatible. You’re confusing “write once” with “compile once”.
The latter is relatively uncommon—Java, UCSD Pascal, and some gaming
engines like ZIL and Inform. The LLVM engine was conceived in that way,
as I understand it, but whenever I have encountered it in the wild, it
has been used as an intermediate stage in a conventional machine-code
compiler, such as CLANG.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/4/2020 4:41 PM, John W Kennedy wrote:

Not at all. “Write once, run everywhere” demands only that the source code be compatible.

So it was write once, run anywhere as long "anywhere" is this one
particular machine.

The compiler for the machine in question wasn't source compatible with
anything else. All the PL/I compilers had language differences, even
among the various IBM compilers. PL/I wasn't even compatible with its
original language definition.

You could write portable PL/I if you were careful about staying within
certain limitations, but that wasn't any different from FORTRAN or COBOL.

I loved PL/I, but this is claiming something for PL/I that was never there.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, November 5, 2020 at 12:13:17 PM UTC+11, Eric Jackson wrote:

On 11/4/2020 4:41 PM, John W Kennedy wrote:

Not at all. “Write once, run everywhere” demands only that the source code be compatible.

So it was write once, run anywhere as long "anywhere" is this one
particular machine.

.
Don't be ridiculous.
.

The compiler for the machine in question wasn't source compatible with anything else.

.
Not true. The language implemented on various other manufacturers'
machines adhered to the standard.
.

All the PL/I compilers had language differences, even
among the various IBM compilers.

.
Rubbish. Over time, IBM enhanced their main PL/I compiler (originally PL/I-F). With the OPTIMISING and CHECKOUT compilers in c.1970, some structured programming features were added, including DO FOREVER; LEAVE; and ITERATE;
(for exiting loops before normal termination of the loop). Similar features were not added to FORTRAN until decades later.
.
The PL/I for OS/2 compiler was introduced in c. 1994,
and it contained a great number of new features.
That compiler became the principal compiler for IBM
machines when it was ported to the mainframe.
In about 1999, new language facilities and built-ins
were added to the language to deal with Y2K.
.
Despite all these changes, old programs were upwards compatible.
.
IBM produced a subset PL/I compiler (D) for the smaller S/360 machines.
.

PL/I wasn't even compatible with its
original language definition.

.
Really?
.

You could write portable PL/I if you were careful about staying within certain limitations, but that wasn't any different from FORTRAN or COBOL.

I loved PL/I, but this is claiming something for PL/I that was never there.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/4/20 8:13 PM, Eric Jackson wrote:

On 11/4/2020 4:41 PM, John W Kennedy wrote:

Not at all. “Write once, run everywhere” demands only that the source
code be compatible.

So it was write once, run anywhere as long "anywhere" is this one
particular machine.

The compiler for the machine in question wasn't source compatible with anything else.  All the PL/I compilers had language differences, even
among the various IBM compilers.  PL/I wasn't even compatible with its original language definition.

You could write portable PL/I if you were careful about staying within certain limitations, but that wasn't any different from FORTRAN or COBOL.

I loved PL/I, but this is claiming something for PL/I that was never there.

PL/I put a great deal more effort into making data declarations
universal, by specifying exact precisions, blocking machine-dependent
mappings (such as character string over binary integer) and the like. Of course, this is largely a dead issue today, since two's-complement
integers of size 2^n bits, IEEE floating point, and Unicode have largely
eaten the world. Compare that to the madness in IBM’s eight pre-360
product families alone.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, November 3, 2020 at 12:49:43 PM UTC+11, Eric Jackson wrote:

On 11/1/2020 7:55 PM, Robin Vowels wrote:

PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added
about 45 seconds to the compile-link-go sequence.

.

Most often serious programs were compiled a few times and then run many times. Student programs are compiled until the student hopes the errors
are gone and never run again.

Nobody used PL/C for serious commercial or scientific work. It never
had extended floating point, the macro facility nor the fixed decimal
data type.

.
For the record, A. B. Tucker compared several compilers, including PL/C, performing matrix inversion on a 20 x 20 matrix, in each case. [1]
The matrix is declared as FLOAT DECIMAL (16).

Times were (Table 9-4, page 279):
compile time execution time
Burroughs B6700 PL/I 7.25 secs 6.10 secs
IBM 370/145 PL/I(F) 14.49 secs 6.31 secs
IBM 370/145 PL/I (Optimiser) 25.92 secs 5.77 secs
IBM 370/145 PL/C 1.37 secs 16.07 secs

Link times for the two IBM compilers are not included. For that
you'd need to add some 30 seconds.

PL/C compiled ten times faster than the two IBM compilers.
The total time (compile + execution) for PL/C was half the compile
time for IBM PL/I Optimising compiler, and just over the compile time
for PL/I(F).
When you add in the link time for the IBM compilers, PL/C
is about four times faster for this task.

[1] A. B. Tucker, Programming languages, McGraw-Hill, 1977.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Robin Vowels <robin.vowels@gmail.com> wrote:

On Tuesday, November 3, 2020 at 12:49:43 PM UTC+11, Eric Jackson wrote:

On 11/1/2020 7:55 PM, Robin Vowels wrote:

PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added
about 45 seconds to the compile-link-go sequence.

.

Most often serious programs were compiled a few times and then run many
times. Student programs are compiled until the student hopes the errors
are gone and never run again.

Nobody used PL/C for serious commercial or scientific work. It never
had extended floating point, the macro facility nor the fixed decimal
data type.

.
For the record, A. B. Tucker compared several compilers, including PL/C, performing matrix inversion on a 20 x 20 matrix, in each case. [1]
The matrix is declared as FLOAT DECIMAL (16).

Times were (Table 9-4, page 279):
compile time execution time
Burroughs B6700 PL/I 7.25 secs 6.10 secs
IBM 370/145 PL/I(F) 14.49 secs 6.31 secs
IBM 370/145 PL/I (Optimiser) 25.92 secs 5.77 secs
IBM 370/145 PL/C 1.37 secs 16.07 secs

Link times for the two IBM compilers are not included. For that
you'd need to add some 30 seconds.

PL/C compiled ten times faster than the two IBM compilers.
The total time (compile + execution) for PL/C was half the compile
time for IBM PL/I Optimising compiler, and just over the compile time
for PL/I(F).
When you add in the link time for the IBM compilers, PL/C
is about four times faster for this task.

[1] A. B. Tucker, Programming languages, McGraw-Hill, 1977.

The other interesting stat is that the extra compile time the Optimizing Compiler used, probably doing optimization, only resulted in a small improvement in execution time.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, November 7, 2020 at 12:54:35 AM UTC+11, b.......@gmail.com wrote:

Robin Vowels <r........@gmail.com> wrote:

On Tuesday, November 3, 2020 at 12:49:43 PM UTC+11, Eric Jackson wrote:

On 11/1/2020 7:55 PM, Robin Vowels wrote:

PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added
about 45 seconds to the compile-link-go sequence.

.

Most often serious programs were compiled a few times and then run many
times. Student programs are compiled until the student hopes the errors
are gone and never run again.

Nobody used PL/C for serious commercial or scientific work. It never
had extended floating point, the macro facility nor the fixed decimal
data type.

.
For the record, A. B. Tucker compared several compilers, including PL/C, performing matrix inversion on a 20 x 20 matrix, in each case. [1]
The matrix is declared as FLOAT DECIMAL (16).

Times were (Table 9-4, page 279):
compile time execution time
Burroughs B6700 PL/I 7.25 secs 6.10 secs
IBM 370/145 PL/I(F) 14.49 secs 6.31 secs
IBM 370/145 PL/I (Optimiser) 25.92 secs 5.77 secs
IBM 370/145 PL/C 1.37 secs 16.07 secs

Link times for the two IBM compilers are not included. For that
you'd need to add some 30 seconds.

PL/C compiled ten times faster than the two IBM compilers.
The total time (compile + execution) for PL/C was half the compile
time for IBM PL/I Optimising compiler, and just over the compile time
for PL/I(F).
When you add in the link time for the IBM compilers, PL/C
is about four times faster for this task.

[1] A. B. Tucker, Programming languages, McGraw-Hill, 1977.

The other interesting stat is that the extra compile time the Optimizing Compiler used, probably doing optimization, only resulted in a small improvement in execution time.

.
Agreed. The improvement in run time was only 0.54 seconds in 6 seconds,
or about 10%.
.
Tucker does not appear to have specified the REORDER option
for the Optimising compiler, nor did I notice anywhere whether
a compiler option to optimise was specified.
.
Some years ago, a similar comparison was made between Pascal
and PL/I Optimising compiler. The program was performing operations
on COMPLEX data.
The author made two blunders. The first was that he failed to specify
the REORDER option for the PL/I program, so it could not carry out
a complete optimisation. I ran the program as it was,
and also with the REORDER option. The improvement
was about 10%.
The second blunder related to the COMPLEX arithmetic operations.
Pascal does not have COMPLEX data type. The author translated the
Pascal program to PL/I and ran that. The PL/I version mimicked
the Pascal. It did not use COMPLEX. When I modified the PL/I program
to use COMPLEX data, it ran another 10% faster.
.
The moral about COMPLEX? The more information that the compiler has,
the better can it do the optimisation.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/6/20 8:54 AM, Peter Flass wrote:

Robin Vowels <robin.vowels@gmail.com> wrote:

On Tuesday, November 3, 2020 at 12:49:43 PM UTC+11, Eric Jackson wrote:

On 11/1/2020 7:55 PM, Robin Vowels wrote:

PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added
about 45 seconds to the compile-link-go sequence.

.

Most often serious programs were compiled a few times and then run many
times. Student programs are compiled until the student hopes the errors
are gone and never run again.

Nobody used PL/C for serious commercial or scientific work. It never
had extended floating point, the macro facility nor the fixed decimal
data type.

.
For the record, A. B. Tucker compared several compilers, including PL/C,
performing matrix inversion on a 20 x 20 matrix, in each case. [1]
The matrix is declared as FLOAT DECIMAL (16).

Times were (Table 9-4, page 279):
compile time execution time
Burroughs B6700 PL/I 7.25 secs 6.10 secs
IBM 370/145 PL/I(F) 14.49 secs 6.31 secs
IBM 370/145 PL/I (Optimiser) 25.92 secs 5.77 secs
IBM 370/145 PL/C 1.37 secs 16.07 secs

Link times for the two IBM compilers are not included. For that
you'd need to add some 30 seconds.

PL/C compiled ten times faster than the two IBM compilers.
The total time (compile + execution) for PL/C was half the compile
time for IBM PL/I Optimising compiler, and just over the compile time
for PL/I(F).
When you add in the link time for the IBM compilers, PL/C
is about four times faster for this task.

[1] A. B. Tucker, Programming languages, McGraw-Hill, 1977.

The other interesting stat is that the extra compile time the Optimizing Compiler used, probably doing optimization, only resulted in a small improvement in execution time.

Without knowing the OPT setting or whether the code is marked REORDER,
that’s essentially meaningless.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, November 7, 2020 at 7:59:07 AM UTC+11, John W. Kennedy wrote:

On 11/6/20 8:54 AM, Peter Flass wrote:

Robin Vowels <r........@gmail.com> wrote:

On Tuesday, November 3, 2020 at 12:49:43 PM UTC+11, Eric Jackson wrote: >>> On 11/1/2020 7:55 PM, Robin Vowels wrote:

PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added
about 45 seconds to the compile-link-go sequence.

.

Most often serious programs were compiled a few times and then run many >>> times. Student programs are compiled until the student hopes the errors >>> are gone and never run again.

Nobody used PL/C for serious commercial or scientific work. It never
had extended floating point, the macro facility nor the fixed decimal >>> data type.

.
For the record, A. B. Tucker compared several compilers, including PL/C, >> performing matrix inversion on a 20 x 20 matrix, in each case. [1]
The matrix is declared as FLOAT DECIMAL (16).

Times were (Table 9-4, page 279):
compile time execution time
Burroughs B6700 PL/I 7.25 secs 6.10 secs
IBM 370/145 PL/I(F) 14.49 secs 6.31 secs
IBM 370/145 PL/I (Optimiser) 25.92 secs 5.77 secs
IBM 370/145 PL/C 1.37 secs 16.07 secs

Link times for the two IBM compilers are not included. For that
you'd need to add some 30 seconds.

PL/C compiled ten times faster than the two IBM compilers.
The total time (compile + execution) for PL/C was half the compile
time for IBM PL/I Optimising compiler, and just over the compile time
for PL/I(F).
When you add in the link time for the IBM compilers, PL/C
is about four times faster for this task.

[1] A. B. Tucker, Programming languages, McGraw-Hill, 1977.

The other interesting stat is that the extra compile time the Optimizing Compiler used, probably doing optimization, only resulted in a small improvement in execution time.

Without knowing the OPT setting or whether the code is marked REORDER, that’s essentially meaningless.

I said that REORDER wasn't used.
And the info is not meaningless.
The fact is that the optimiser took twice as long as PL/I-F and produced only
a marginal improvement in execution speed.
What can be said is that even if the OPT option was set for low optimisation, full optimisation would have been intolerably longer.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <9dad9b74-9b49-4f9c-a37f-53acade87d9dn@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> writes:

On Saturday, November 7, 2020 at 7:59:07 AM UTC+11, John W. Kennedy wrote:

On 11/6/20 8:54 AM, Peter Flass wrote:=20

Robin Vowels <r........@gmail.com> wrote:=20

On Tuesday, November 3, 2020 at 12:49:43 PM UTC+11, Eric Jackson wrote= >:=20

On 11/1/2020 7:55 PM, Robin Vowels wrote:=20

PL/C was a serious PL/I compiler. Yes, though it was intended for st=

udent use,=20

it was also intended for general use, because it was so much faster =

at compilation=20

than PL/I-F. The weakness of the IBM offering was the link editor th=

at added=20

about 45 seconds to the compile-link-go sequence.=20

.=20

Most often serious programs were compiled a few times and then run ma=

ny=20

times. Student programs are compiled until the student hopes the erro=

rs=20

are gone and never run again.=20
=20
Nobody used PL/C for serious commercial or scientific work. It never=

=20

had extended floating point, the macro facility nor the fixed decimal=

=20

data type.=20

.=20
For the record, A. B. Tucker compared several compilers, including PL/=

C,=20

performing matrix inversion on a 20 x 20 matrix, in each case. [1]=20
The matrix is declared as FLOAT DECIMAL (16).=20
=20
Times were (Table 9-4, page 279):=20
compile time execution time=20
Burroughs B6700 PL/I 7.25 secs 6.10 secs=20
IBM 370/145 PL/I(F) 14.49 secs 6.31 secs=20
IBM 370/145 PL/I (Optimiser) 25.92 secs 5.77 secs=20
IBM 370/145 PL/C 1.37 secs 16.07 secs=20
=20
Link times for the two IBM compilers are not included. For that=20
you'd need to add some 30 seconds.=20
=20
PL/C compiled ten times faster than the two IBM compilers.=20
The total time (compile + execution) for PL/C was half the compile=20
time for IBM PL/I Optimising compiler, and just over the compile time=

=20

for PL/I(F).=20
When you add in the link time for the IBM compilers, PL/C=20
is about four times faster for this task.=20
=20
[1] A. B. Tucker, Programming languages, McGraw-Hill, 1977.=20

=20
The other interesting stat is that the extra compile time the Optimizin=

g=20

Compiler used, probably doing optimization, only resulted in a small=20
improvement in execution time.=20

Without knowing the OPT setting or whether the code is marked REORDER,=20
that=E2=80=99s essentially meaningless.

I said that REORDER wasn't used.
And the info is not meaningless.
The fact is that the optimiser took twice as long as PL/I-F and produced on= ly
a marginal improvement in execution speed.
What can be said is that even if the OPT option was set for low optimisatio= n,
full optimisation would have been intolerably longer.

In situations where source is automatically generated, compiled, and
only used once (doable given the power of the PL/I preprocessor),
unless it runs against a LOT of data, you probably don't want to waste
the time on optimization. But if it does run against a lot of data, or
is compiled once and run a lot more than once, who cares if it takes a
few more minutes to compile? During development, don't turn on the
optimization until you're close enough to done that you want to do
some serious testing, of both correctness and performance.

But all that was back-in-the-day, when the compiler was many passes and
had to be quite small. Doubtless it can have a larger region now.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)