• How to decode PL/I programming language

    From Robin Vowels@21:1/5 to Peter J. Seymour on Tue Oct 27 03:19:26 2020
    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)
  • From Robin Vowels@21:1/5 to c......@gmail.com on Fri Oct 30 03:17:05 2020
    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)
  • From carlos feldman@21:1/5 to All on Fri Oct 30 13:28:46 2020
    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)
  • From Cornell Sternbergh@21:1/5 to All on Sat Oct 31 09:51:23 2020

    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)
  • From Eric Jackson@21:1/5 to All on Sun Nov 1 01:51:35 2020
    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)
  • From Cornell Sternbergh@21:1/5 to Eric Jackson on Sun Nov 1 10:52:25 2020
    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)
  • From John W Kennedy@21:1/5 to Cornell Sternbergh on Sun Nov 1 18:46:30 2020
    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)
  • From Robin Vowels@21:1/5 to Eric Jackson on Sun Nov 1 19:43:43 2020
    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)
  • From Robin Vowels@21:1/5 to Eric Jackson on Sun Nov 1 19:55:49 2020
    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)
  • From John W Kennedy@21:1/5 to Robin Vowels on Mon Nov 2 12:07:08 2020
    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)
  • From Iron Spring Software@21:1/5 to John W Kennedy on Mon Nov 2 14:06:30 2020
    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)
  • From Cornell Sternbergh@21:1/5 to John W. Kennedy on Mon Nov 2 13:07:54 2020
    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)
  • From Iron Spring Software@21:1/5 to John W Kennedy on Mon Nov 2 14:08:25 2020
    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)
  • From John W Kennedy@21:1/5 to Iron Spring Software on Mon Nov 2 20:21:23 2020
    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)
  • From Eric Jackson@21:1/5 to Cornell Sternbergh on Mon Nov 2 17:32:27 2020
    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)
  • From John W Kennedy@21:1/5 to Cornell Sternbergh on Mon Nov 2 20:33:00 2020
    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)
  • From Eric Jackson@21:1/5 to Robin Vowels on Mon Nov 2 17:49:42 2020
    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)
  • From Robin Vowels@21:1/5 to John W. Kennedy on Tue Nov 3 04:04:49 2020
    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)
  • From Robin Vowels@21:1/5 to Cornell Sternbergh on Tue Nov 3 04:11:57 2020
    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)
  • From Robin Vowels@21:1/5 to Eric Jackson on Tue Nov 3 04:22:26 2020
    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)
  • From Peter Flass@21:1/5 to Eric Jackson on Tue Nov 3 10:49:47 2020
    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)
  • From Peter Flass@21:1/5 to Cornell Sternbergh on Tue Nov 3 10:49:49 2020
    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)
  • From wat fiv@21:1/5 to Robin Vowels on Tue Nov 3 16:37:41 2020
    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)
  • From John W Kennedy@21:1/5 to Robin Vowels on Tue Nov 3 20:05:30 2020
    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)
  • From John W Kennedy@21:1/5 to Peter Flass on Tue Nov 3 20:09:10 2020
    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)
  • From Eric Jackson@21:1/5 to Peter Flass on Tue Nov 3 20:31:40 2020
    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)
  • From Cornell Sternbergh@21:1/5 to bearlyabus...@gmail.com on Wed Nov 4 10:14:59 2020
    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)
  • From John W Kennedy@21:1/5 to Eric Jackson on Wed Nov 4 19:41:17 2020
    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)
  • From Eric Jackson@21:1/5 to John W Kennedy on Wed Nov 4 17:13:13 2020
    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)
  • From Robin Vowels@21:1/5 to Eric Jackson on Wed Nov 4 21:38:36 2020
    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)
  • From John W Kennedy@21:1/5 to Eric Jackson on Thu Nov 5 22:24:19 2020
    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)
  • From Robin Vowels@21:1/5 to Eric Jackson on Thu Nov 5 20:45:01 2020
    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)
  • From Peter Flass@21:1/5 to Robin Vowels on Fri Nov 6 06:54:34 2020
    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)
  • From Robin Vowels@21:1/5 to b.......@gmail.com on Fri Nov 6 07:57:20 2020
    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)
  • From John W Kennedy@21:1/5 to Peter Flass on Fri Nov 6 15:58:46 2020
    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)
  • From Robin Vowels@21:1/5 to John W. Kennedy on Fri Nov 6 17:58:44 2020
    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)
  • From Richard L. Hamilton@21:1/5 to Robin Vowels on Sun Dec 6 04:39:41 2020
    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)