Create loopy test program for PL/I #311
Conversation
Add PL/I code identical to the COBOL pendant.
|
Reason for reopen: pull request was not merged. |
|
Hello. Thanks for contributing! 🙏 However, if this program can't be run in a benchmark together with the other languages, it doesn't really belong, I think. |
|
On which platform runs then the benchmark please? |
|
The benchmark runs on whatever computers people choose to run them on. For both @bddicken and me that means MacOS. But any environment that can run |
|
Thank you first; I will try my best.
I wish you all a happy new year!
Peter Strömberg ***@***.***> (időpont: 2024. dec. 31., K,
18:17) ezt írta:
… The benchmark runs on whatever computers people choose to run them on. For
both @bddicken <https://github.com/bddicken> and me that means MacOS. But
any environment that can run compile.sh and run.sh will do. If you add
entries to those files for this program, we can start preparing to merge. I
would also need instructions (or just a link) on how to install the
toolchain. Please also consider providing a hello-world implementation,
because we use that to measure start-times for the various languages.
—
Reply to this email directly, view it on GitHub
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQEP3XFPQF4B7A7L63HSYL2ILGRRAVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRWGYYDINZUGA>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
Happy new year! |
|
A little belatedly, I looked at compile.sh and was horrified. |
Oh, no. I'm sorry that it created that impression! What I mean is that it needs to fit in this “framework”. So, if you have a way to compile and run it on Ubuntu that can be added to Now that you have given me hints on what I may need to install on my Mac, that is great too.
Tell me about it. It has taken me a lot of time to get to here: https://pez.github.io/languages-visualizations/ Looking forward to be able to include PL/I! |
This version was compiled and tested by the "official" compile and run scripts.
|
Hello Peter,
I have compiled, and tested my new version with the "official" scripts.
Here the new code:
languages/loops/PL1/loopy at main · markons/languages
<https://github.com/markons/languages/blob/main/loops/PL1/loopy>
To enable the compile, one must install the Iron Spring Software -
Documentation <http://www.iron-spring.com/doc.html> PL/I in a Unix
environment.
I have used it in my WSL Ubuntu installation. It took some time, but all
because of my missing Unix experience.
For an experienced one it is rather straightforward; perhaps the
Here the benchmarking FYI.
*Checking pl1output: 1955594 *1950000 (the second number is only a trace
from me)
*Check passed*
*Benchmarking pl1*
*Benchmark 1: ./pl1/code/loopy.exe 40*
* Time (mean ± σ): 47.092 s ± 0.205 s [User: 45.871 s, System:
0.010 s]*
* Range (min … max): 46.899 s … 47.308 s 3 runs*
(On an IBM mainframe the results could be slightly better of course ;)
Is this information sufficient to include my PL/I in the project?
Best regards
Gabor
…On Fri, Jan 3, 2025 at 1:38 PM Peter Strömberg ***@***.***> wrote:
Does this mean that on a given machine, all the compilers of the
programming languages listed in the script must be installed?
Oh, no. I'm sorry that it created that impression! What I mean is that it
needs to fit in this “framework”. So, if you have a way to compile and run
it on Ubuntu that can be added to compile.sh and run.sh, that is totally
OK. Please add those entries and we will have this PR merged. (And I repeat
my wish for a hello-world contribution as well to be included.)
Now that you have given me hints on what I may need to install on my Mac,
that is great too.
installing all languages is a Sisyphean task
Tell me about it. It has taken me a lot of time to get to here:
https://pez.github.io/languages-visualizations/
Looking forward to be able to include PL/I!
—
Reply to this email directly, view it on GitHub
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQEP3QBXZ2N76ZHNNXOJOD2I2AFRAVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRZGE3DCNZTGA>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
Hello again Gabor, Awesome to see this! The performance is miles better than COBOL. 😄 You don't need to link the new code, btw, it is updated on this PR every time you push new code to the branch on your fork. Three things:
As for instructions on how to install the toolchain. So far we have not had that, but I think it would be a good idea to include that somehow. How about we create a file |
|
Hello Peter,
Thanks for the prompt feedback. I'll try to gather the infos you need.
Regards
Gabor
…On Thu, Jan 9, 2025 at 4:59 PM Peter Strömberg ***@***.***> wrote:
Hello again Gabor,
Awesome to see this! The performance is miles better than COBOL. 😄
You don't need to link the new code, btw, it is updated on this PR every
time you push new code to the branch on your fork.
Three things:
1. The naming of the program file. For all other languages the code is
always in a <benchmark>/<language>/code.<extension> file. So for
*loops* and *C*, this is loops/code.c. I don't even remember if file
extensions are a thing on mainframes, but I imagine that loopy could be
placed in loops/pl1/code.pl1, if .pl1 is some extension that could be
used?
2. Please update compile.sh and run.sh with the commands necessary to
compile and run the program. Here it will get evident for you why the
program should be named code.pl1, because the same commands would be
used if someone (you?) contribute other benchmark implementations.
3. Speaking about other benchmark implementations, I would very much
like if you included an implementation of hello-world. We use this for
measuring start times of each program.
As for instructions on how to install the toolchain. So far we have not
had that, but I think it would be a good idea to include that somehow. How
about we create a file hello-world/pl1/README.md where we say a few words
about the language and also can link to the instructions on how to install
the toolchain on a Unix machine? Then other languages can follow that model.
—
Reply to this email directly, view it on GitHub
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQEP3S5WVD6SXQ4QJTFRPT2J2MFRAVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBQGY2DEMZVGI>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
On Thu, Jan 9, 2025 at 4:59 PM Peter Strömberg ***@***.***> wrote:
Hello again Gabor,
Awesome to see this! The performance is miles better than COBOL. 😄
You don't need to link the new code, btw, it is updated on this PR every
time you push new code to the branch on your fork.
Three things:
1. The naming of the program file. For all other languages the code is
always in a <benchmark>/<language>/code.<extension> file. So for
*loops* and *C*, this is loops/code.c. I don't even remember if file
extensions are a thing on mainframes, but I imagine that loopy could be
placed in loops/pl1/code.pl1, if .pl1 is some extension that could be
used?
OK, I have changed the program name in languages/loops/PL1/code.pli
at main · markons/languages
<https://github.com/markons/languages/blob/main/loops/PL1/code.pli> to
code.pli
As I run the program on Linux, using the IronSpring compiler, I can
do this; the .pli extension (or alternatively the .pl1) is
valid there.
On the mainframes, there is no extension for program names. Still
maximal 8 alphanumeric characters as for >50 years.
1. Please update compile.sh and run.sh with the commands necessary to
compile and run the program. Here it will get evident for you why the
program should be named code.pl1, because the same commands would be
used if someone (you?) contribute other benchmark implementations.
I call compile.sh like this:
*compile 'pl1' 'plic pl1/code/loopy.pli -o pl1/loopy.obj && ld
-L/usr/lib32 --oformat=elf32-i386 -melf_i386 -z muldefs -Bstatic -e main -t
-o pl1/code/loopy.exe pl1/loopy.obj -lprf -lc > pl1/loopy.map' *
I call run.sh as:
*run "pl1" "./pl1/code/loopy.exe" "./pl1/code/loopy.exe" "40"*
…
1. Speaking about other benchmark implementations, I would very much
like if you included an implementation of hello-world. We use this for
measuring start times of each program.
As for instructions on how to install the toolchain. So far we have not
had that, but I think it would be a good idea to include that somehow. How
about we create a file hello-world/pl1/README.md where we say a few words
about the language and also can link to the instructions on how to install
the toolchain on a Unix machine? Then other languages can follow that model.
—
Reply to this email directly, view it on GitHub
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQEP3S5WVD6SXQ4QJTFRPT2J2MFRAVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBQGY2DEMZVGI>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
*Sorry I've sent the answer partially. Here a more complete answer.*
*The naming of the program file. For all other languages the code is
always in a <benchmark>/<language>/code.<extension> file. So
for loops and C, this is loops/code.c. I don't even remember if file
extensions are a thing on mainframes, but I imagine that loopy could be
placed in loops/pl1/code.pl1, if .pl1 is some extension that could be used?*
*OK, I have changed the program name in languages/loops/PL1/code.pli at
main · markons/languages
<https://github.com/markons/languages/blob/main/loops/PL1/code.pli> to
code.pli As I run the program on Linux, using the IronSpring compiler,
I can do this; the .pli extension (or alternatively the .pl1) is
valid there. On the mainframes, there is no extension for program
names. Still maximal 8 alphanumeric characters as for >50 years.*
*Please update compile.sh and run.sh with the commands necessary to
compile and run the program. Here it will get evident for you why the
program should be named code.pl1, because the same commands would be used
if someone (you?) contribute other benchmark implementations.*
* I call compile.sh like this:*
*compile 'pl1' 'plic pl1/code/loopy.pli -o pl1/loopy.obj && ld
-L/usr/lib32 --oformat=elf32-i386 -melf_i386 -z muldefs -Bstatic -e main -t
-o pl1/code/loopy.exe pl1/loopy.obj -lprf -lc > pl1/loopy.map' *
* I call run.sh as:*
*run "pl1" "./pl1/code/loopy.exe" "./pl1/code/loopy.exe" "40"*
Please rename "loopy" into "code" throughout if needed.
*Speaking about other benchmark implementations, I would very much like if
you included an implementation of hello-world. We use this for measuring
start times of each program.*
*OK, done.*
*As for instructions on how to install the toolchain. So far we have not
had that, but I think it would be a good idea to include that somehow. How
about we create a file hello-world/pl1/README.md where we say a few words
about the language and also can link to the instructions on how to install
the toolchain on a Unix machine? Then other languages can follow that
model.*
* Do I need to create a "**hello-world/pl1**" subdirectory under my "PL1"
?*
Regards
Gabor
…
On Thu, Jan 9, 2025 at 4:59 PM Peter Strömberg ***@***.***> wrote:
Hello again Gabor,
Awesome to see this! The performance is miles better than COBOL. 😄
You don't need to link the new code, btw, it is updated on this PR every
time you push new code to the branch on your fork.
Three things:
1. The naming of the program file. For all other languages the code is
always in a <benchmark>/<language>/code.<extension> file. So for
*loops* and *C*, this is loops/code.c. I don't even remember if file
extensions are a thing on mainframes, but I imagine that loopy could be
placed in loops/pl1/code.pl1, if .pl1 is some extension that could be
used?
2. Please update compile.sh and run.sh with the commands necessary to
compile and run the program. Here it will get evident for you why the
program should be named code.pl1, because the same commands would be
used if someone (you?) contribute other benchmark implementations.
3. Speaking about other benchmark implementations, I would very much
like if you included an implementation of hello-world. We use this for
measuring start times of each program.
As for instructions on how to install the toolchain. So far we have not
had that, but I think it would be a good idea to include that somehow. How
about we create a file hello-world/pl1/README.md where we say a few words
about the language and also can link to the instructions on how to install
the toolchain on a Unix machine? Then other languages can follow that model.
—
Reply to this email directly, view it on GitHub
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQEP3S5WVD6SXQ4QJTFRPT2J2MFRAVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBQGY2DEMZVGI>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
😂 Thanks for updating! What we need for merging this PR is that
The hello-world program should go under When you have moved the code there you should be able to cd to to compile the program(s), and: to run them. And from the Depending on how many toolchains you have on your machine it can take a while to compile and run everything. Unfortunately the only way, so far, to run only one language is to comment out all the rest. Here's a guess of what should go into compile 'pl1' 'plic pl1/code.pli -o pl1/code.obj && ld -L/usr/lib32 --oformat=elf32-i386 -melf_i386 -z muldefs -Bstatic -e main -t -o pl1/code.exe pl1/code.obj -lprf -lc > pl1/code.map' This will be a bit too specific and only for 32-bit X86, but it's a start. 😄 And for run "PL1" "./pl1/code.exe" "./pl1/code.exe" "${input}"I hope this makes sense. The point is that the same script is used for compiling both loops and hello-world (and any other benchmark someone contributes) and that which one is compiled is determined from the directory from which |
Removed to hello-world
Single apostrophes are more common as delimiter.
|
Dear Peter,
huh. I've succeeded in implementing the third sample "levenshtein
algorithm" in Iron Spring's PL/I.
It was not so trivial; it still has problems implementing dynamic size
array allocation.
I've changed the algorithm slightly by pre-allocate the "distance" matrix
as a fixed size array.
I've tested it on a couple of samples, and checked the results using Online
calculator: Levenshtein Distance <https://planetcalc.com/1721/> .
Then I've had a look at 'input.txt' which generates the in 'check.sh'
required values; it has a length of 3000 characters, which is too long as a
runtime parameter in PL/I. It has a maximum length of 100 characters.
My question: is it possible, my PL/I program reads the 'input.txt' file
directly from the standard directory, instead of getting it as a runtime
parameter?
Alternatively, I forget the Levensthine algorithm, and develop only the
hello and the loop textst for PL/I, similar to Cobol.
Which one is suitable for the project? Honestly speaking, for me the first
one is preferred.
Regards
Gábor
…On Thu, Jan 9, 2025 at 10:00 PM Peter Strömberg ***@***.***> wrote:
On the mainframes, there is no extension for program names. Still maximal
8 alphanumeric characters as for >50 years.*
😂
Thanks for updating! What we need for merging this PR is that compile.sh
and run.sh are updated with the commands for compiling and running the
PL1 benchmarks. Since both these scripts will be used for all PL1 programs,
the commands need to be stripped of any references to loopy.
- Do I need to create a "*hello-world/pl1*" subdirectory under my "PL1"
The hello-world program should go under hello-world/PL1/code.pli, where
hello-world is a sibling directory to loops.
When you have moved the code there you should be able to cd to hello-world
and run
../compile.sh
to compile the program(s), and:
../run.sh
to run them.
And from the loops directory you should be able to do the same for that
program.
Depending on how many toolchains you have on your machine it can take a
while to compile and run everything. Unfortunately the only way, so far, to
run only one language is to comment out all the rest.
Here's a guess of what should go into compile.sh:
compile 'pl1' 'plic pl1/code.pli -o pl1/code.obj && ld -L/usr/lib32 --oformat=elf32-i386 -melf_i386 -z muldefs -Bstatic -e main -t -o pl1/code.exe pl1/code.obj -lprf -lc > pl1/code.map'
This will be a bit too specific and only for 32-bit X86, but it's a start.
😄
And for run.sh
run "PL1" "./pl1/code.exe" "./pl1/code.exe" "${input}"
I hope this makes sense. The point is that the same script is used for
compiling both *loops* and *hello-world* (and any other benchmark someone
contributes) and that which one is compiled is determined from the
directory from which compile.sh is run. Same for run.sh.
—
Reply to this email directly, view it on GitHub
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQEP3RVFVW4YG7QRCFVDPD2J3PO3AVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBRGIZTOMJUGM>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
Hi! Yes, let the program read from the file instead. In this PR #365 I am actually proposing to change it so that all programs will read from a file instead of from the command line. (If we end up going with that proposal there will be some more work for the programs to also measure the run times and such, but you can disregard that for now.) |
New directory "pl1" created for the PL/I code
code copied to new directory "pl1"
|
Hi! Now we have started moving over to the in-process runner (and thus a Levenshtein program that should read from file instead of from command line args). To get the PL1 contributions over will involve writing a benchmarking utility that does the running and measuring of the benchmarked function. See the updated project README for more on this and to find reference implementations. Let me know if there are something unclear or if you think I can help in some way. |
|
Hi!
Sorry for the late reply. I was deep in the development of the PL/I
implementation of the Levenhstein algorithm.
Now I'm happy as it runs OK with the check. It was hard work, as the Iron
Spring PL/I has some features which are not 100% compatible with the
mainframe PL/I which I know.
I hope I can next week deliver the commands for the compile/run steps.
As I've said, the basis is the implementation of the Iron Spring compiler
on your side, but it is a straightforward process for the Unix profis.
Regards
Gábor
…On Sun, Jan 26, 2025 at 6:18 PM Peter Strömberg ***@***.***> wrote:
Hi! Now we have started moving over to the in-process runner (and thus a
Levenshtein program that should read from file instead of from command line
args).
To get the PL1 contributions over will involve writing a benchmarking
utility that does the running and measuring of the benchmarked function.
See the updated project README for more on this and to find reference
implementations. Let me know if there are something unclear or if you think
I can help in some way.
—
Reply to this email directly, view it on GitHub
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQEP3S7KQRZULXS4LXT2ZD2MUKE3AVCNFSM6AAAAABULZMRDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJUGUYTGMJVGI>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
Load source code
Add PL/I code identical to the COBOL pendant.
I have:
Description of changes
Directory PL1 added for the PL/I language.
The code on loopy.pl1 was tested under z/OS ADCD , PL/I Enterprise Edition V3.
ADCD run on a somewhate lame PC (Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz ); the CPU time was 46MIN 59.65SEC.
An identical run on a "real" mainframe would be welcome.