search

JvanKatwijk / algol-60-compiler

an algol 60 to C translator (old stuff but fun project)
GNU General Public License v2.0
35 stars 7 forks source link

non-compiling c code #1

Open lukacsarpad opened 5 years ago

lukacsarpad commented 5 years ago

ei.txt The attached file is compiled to a c code that cannot be compiled. No error message is given, however.

The same code runs with marst.

JvanKatwijk commented 5 years ago

wow great. A first look at the outcome shows that probably something is overwritten in the compiler I'll look at it

Op di 4 dec. 2018 om 00:21 schreef lukacsarpad notifications@github.com:

ei.txt https://github.com/JvanKatwijk/algol-60-compiler/files/2641655/ei.txt The attached file is compiled to a c code that cannot be compiled. No error message is given, however.

The same code runs with marst.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/algol-60-compiler/issues/1, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwExBl_5SA0DEBWwTatgTDXi3lzubks5u1bHsgaJpZM4Y_nCc .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

lukacsarpad commented 5 years ago

Thanks a lot! The code actually is part of NUMAL from CWI.

JvanKatwijk commented 5 years ago

well, it seems the constant bounds in a local procedure are causing some problems. The compiler tries to be smart with arrays with constant bounds, and something goes wrong. By removing the "optimization" the problem is solved. I really have to dig deep into the code to see why it is going wrong with constant bound arrays in inner procedures, the code was written > 15 years ago. But it is a nice challenge and I really want to know what is happening deep inside

Anyway, the program you gave is running, its output is [jan@lenovo Downloads]$ time ./ei 1 -1.331595026e14 2 -1.851748801e14 3 -2.749660460e14 4 -4.379633658e14 5 -7.477981149e14 6 -1.361257182e15 7 191.5047433 8 440.3798995 9 1037.878290 10 2492.228976

real 0m0.003s user 0m0.000s sys 0m0.003s

Thanks for pointing out the issue. and for using the compiler

The github page is update with source for a compiler which does not understand constant bounds in arrays

all the best jan

Op di 4 dec. 2018 om 13:37 schreef lukacsarpad notifications@github.com:

Thanks a lot! The code actually is part of NUMAL from CWI.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/algol-60-compiler/issues/1#issuecomment-444085295, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwOjHWazw_qEPZPazpopjUGX8UwkMks5u1mxwgaJpZM4Y_nCc .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

lukacsarpad commented 5 years ago

I downloaded the new version, and first I realized that I had a patch to make it compile, in frontend.c, line 8024, jff-algol.c, line 70, and in runtime.c, line 616, a format string (I think, "%s") is needed.

However, after that, for the same file, I get the error message jff-algol c35080.alg Analysis, line 95 (file c35080.alg):Could not find abs (only reported once) Analysis, line 95 (file c35080.alg):No identification for binary operator > analysis c35080.alg complete, 2 errors Error code 256, compiling c35080.alg aborted after front end

For a simple test, another weird error message: jff-algol test.alg file test.alg: On line 9 (char 10), symbol -4; outreal(1,x); end; ����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������� illegal, skipping input until 39 parsing test.alg complete, 1 errors Error code 256, compiling test.alg aborted after front end test.txt

lukacsarpad commented 5 years ago

I replaced in line 9 the real literal with 1.e-4. Now it is compiled by jff-algol, but the result crashes with a segmentation fault. test.txt

JvanKatwijk commented 5 years ago

the abs should be fabs

What are the patches? here it is working fine

wrt the test.txt file, probably the denotation of the number

Op di 4 dec. 2018 om 20:04 schreef lukacsarpad notifications@github.com:

I downloaded the new version, and first I realized that I had a patch to make it compile, in frontend.c, line 8024, jff-algol.c, line 70, and in runtime.c, line 616, a format string (I think, "%s") is needed.

However, after that, for the same file, I get the error message jff-algol c35080.alg Analysis, line 95 (file c35080.alg):Could not find abs (only reported once) Analysis, line 95 (file c35080.alg):No identification for binary operator > analysis c35080.alg complete, 2 errors Error code 256, compiling c35080.alg aborted after front end

For a simple test, another weird error message: jff-algol test.alg file test.alg: On line 9 (char 10), symbol -4; outreal(1,x); end; ����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������� illegal, skipping input until 39 parsing test.alg complete, 1 errors Error code 256, compiling test.alg aborted after front end test.txt https://github.com/JvanKatwijk/algol-60-compiler/files/2645661/test.txt

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/algol-60-compiler/issues/1#issuecomment-444217160, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwKj4v378DHD9n2wm468qHXnySA6Iks5u1scfgaJpZM4Y_nCc .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

lukacsarpad commented 5 years ago

Interestingly, if I implement abs(x), the numal ei code compiles, but crashes with a segmentation fault. However, this new version compiles with the old compiler, but gives wrong results. The correct results (run with marst) is 1 1.89511781636 2 4.954234356 3 9.93383257063 4 19.6308744701 5 40.1852753558 6 85.9897621424 7 191.504743336 8 440.379899535 9 1037.87829072 10 2492.22897624

lukacsarpad commented 5 years ago

I changed abs to fabs. Now it compiles with the new version, but the compiled executable crashes. I am using gcc under linux. I'll attach the patches. printf-strict.patch.txt

JvanKatwijk commented 5 years ago

what is your environment, here I get the right results and the small test.txt file compiles and executes well can you send the resulting C code?

Op di 4 dec. 2018 om 20:13 schreef lukacsarpad notifications@github.com:

Interestingly, if I implement abs(x), the numal ei code compiles, but crashes with a segmentation fault. However, this new version compiles with the old compiler, but gives wrong results. The correct results (run with marst) is 1 1.89511781636 2 4.954234356 3 9.93383257063 4 19.6308744701 5 40.1852753558 6 85.9897621424 7 191.504743336 8 440.379899535 9 1037.87829072 10 2492.22897624

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/algol-60-compiler/issues/1#issuecomment-444221152, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwFZFH50A76e8kdLKbTAQYbMEGf9lks5u1slugaJpZM4Y_nCc .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

lukacsarpad commented 5 years ago

I am using ubuntu linux 18.04, gcc version 7.3.0. The resulting c file is attached. c35080b.c.txt c35080b.alg.txt

JvanKatwijk commented 5 years ago

[jan@lenovo Downloads]$ time ./c35080b 1 -1142.306180 2 -1572.708543 3 -2315.988660 4 -3664.602617 5 -6226.004459 6 -11292.35887 7 191.5047433 8 440.3798995 9 1037.878290 10 2492.228976

real 0m0.003s user 0m0.000s sys 0m0.002s Compiling the source is fine here, as is the execution. Comparing the C files does not show a difference, apart from the formatting, So it must be something in the rt system I'll install an Ubuntu 18 version tomorrow (well, not only for this actually), then we have comparable development environments

Op di 4 dec. 2018 om 20:19 schreef lukacsarpad notifications@github.com:

I am using ubuntu linux 18.04, gcc version 7.3.0. The resulting c file is attached. c35080b.c.txt https://github.com/JvanKatwijk/algol-60-compiler/files/2645734/c35080b.c.txt c35080b.alg.txt https://github.com/JvanKatwijk/algol-60-compiler/files/2645736/c35080b.alg.txt

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/algol-60-compiler/issues/1#issuecomment-444223678, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwKagyP2wqJjVh3pDj42m93gkgq3Jks5u1srcgaJpZM4Y_nCc .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

JvanKatwijk commented 5 years ago

I just installed the compiler on Stretch (RPI3) and no problems there (gcc version 6.3.0 20170516 (Raspbian 6.3.0-18+rpi1+deb9u1) So curious what Ubuntu will bring us

Op di 4 dec. 2018 om 20:42 schreef jan van katwijk j.vankatwijk@gmail.com:

[jan@lenovo Downloads]$ time ./c35080b 1 -1142.306180 2 -1572.708543 3 -2315.988660 4 -3664.602617 5 -6226.004459 6 -11292.35887 7 191.5047433 8 440.3798995 9 1037.878290 10 2492.228976

real 0m0.003s user 0m0.000s sys 0m0.002s Compiling the source is fine here, as is the execution. Comparing the C files does not show a difference, apart from the formatting, So it must be something in the rt system I'll install an Ubuntu 18 version tomorrow (well, not only for this actually), then we have comparable development environments

Op di 4 dec. 2018 om 20:19 schreef lukacsarpad notifications@github.com:

I am using ubuntu linux 18.04, gcc version 7.3.0. The resulting c file is attached. c35080b.c.txt https://github.com/JvanKatwijk/algol-60-compiler/files/2645734/c35080b.c.txt c35080b.alg.txt https://github.com/JvanKatwijk/algol-60-compiler/files/2645736/c35080b.alg.txt

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/algol-60-compiler/issues/1#issuecomment-444223678, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwKagyP2wqJjVh3pDj42m93gkgq3Jks5u1srcgaJpZM4Y_nCc .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

JvanKatwijk commented 5 years ago

It took a while but I have an Ubuntu 18.04 box running and I can confirm that the compiled code crashes. I have to dig into the code to see what is going on. might take a few days

Op di 4 dec. 2018 om 21:01 schreef jan van katwijk j.vankatwijk@gmail.com:

I just installed the compiler on Stretch (RPI3) and no problems there (gcc version 6.3.0 20170516 (Raspbian 6.3.0-18+rpi1+deb9u1) So curious what Ubuntu will bring us

Op di 4 dec. 2018 om 20:42 schreef jan van katwijk <j.vankatwijk@gmail.com

:

[jan@lenovo Downloads]$ time ./c35080b 1 -1142.306180 2 -1572.708543 3 -2315.988660 4 -3664.602617 5 -6226.004459 6 -11292.35887 7 191.5047433 8 440.3798995 9 1037.878290 10 2492.228976

real 0m0.003s user 0m0.000s sys 0m0.002s Compiling the source is fine here, as is the execution. Comparing the C files does not show a difference, apart from the formatting, So it must be something in the rt system I'll install an Ubuntu 18 version tomorrow (well, not only for this actually), then we have comparable development environments

Op di 4 dec. 2018 om 20:19 schreef lukacsarpad <notifications@github.com

:

I am using ubuntu linux 18.04, gcc version 7.3.0. The resulting c file is attached. c35080b.c.txt https://github.com/JvanKatwijk/algol-60-compiler/files/2645734/c35080b.c.txt c35080b.alg.txt https://github.com/JvanKatwijk/algol-60-compiler/files/2645736/c35080b.alg.txt

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/algol-60-compiler/issues/1#issuecomment-444223678, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwKagyP2wqJjVh3pDj42m93gkgq3Jks5u1srcgaJpZM4Y_nCc .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

JvanKatwijk commented 5 years ago

It turned out to be a small but interesting error. The specification of one function contained a typo, so the compiler interpreted the result of the function as an integer, while it was a pointer. The Ubuntu compiler returned then the lowest 32 bits of the pointer as an address, conversion to the pointer result was then by sign extending the result, so that the upper 32 bits of the pointer were all set to 1.

Interesting to note that - while this was certainly an error in my code - that both the fedora 28 and 29 gcc versions as well as the Raspberry version were more lenient and gave back the whole 64 bit pointer

Obviously in the time of development - 2002 - int's and pointers were the same size, so that was not an issue then

best jan

Op do 6 dec. 2018 om 21:37 schreef jan van katwijk j.vankatwijk@gmail.com:

It took a while but I have an Ubuntu 18.04 box running and I can confirm that the compiled code crashes. I have to dig into the code to see what is going on. might take a few days

Op di 4 dec. 2018 om 21:01 schreef jan van katwijk <j.vankatwijk@gmail.com

:

I just installed the compiler on Stretch (RPI3) and no problems there (gcc version 6.3.0 20170516 (Raspbian 6.3.0-18+rpi1+deb9u1) So curious what Ubuntu will bring us

Op di 4 dec. 2018 om 20:42 schreef jan van katwijk < j.vankatwijk@gmail.com>:

[jan@lenovo Downloads]$ time ./c35080b 1 -1142.306180 2 -1572.708543 3 -2315.988660 4 -3664.602617 5 -6226.004459 6 -11292.35887 7 191.5047433 8 440.3798995 9 1037.878290 10 2492.228976

real 0m0.003s user 0m0.000s sys 0m0.002s Compiling the source is fine here, as is the execution. Comparing the C files does not show a difference, apart from the formatting, So it must be something in the rt system I'll install an Ubuntu 18 version tomorrow (well, not only for this actually), then we have comparable development environments

Op di 4 dec. 2018 om 20:19 schreef lukacsarpad <notifications@github.com

:

I am using ubuntu linux 18.04, gcc version 7.3.0. The resulting c file is attached. c35080b.c.txt https://github.com/JvanKatwijk/algol-60-compiler/files/2645734/c35080b.c.txt c35080b.alg.txt https://github.com/JvanKatwijk/algol-60-compiler/files/2645736/c35080b.alg.txt

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/algol-60-compiler/issues/1#issuecomment-444223678, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwKagyP2wqJjVh3pDj42m93gkgq3Jks5u1srcgaJpZM4Y_nCc .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

lukacsarpad commented 5 years ago

Thank you. I downloaded the new code, built an ubuntu package, and installed it. However, the results for x < 6 are still wrong. It seems that numeric literals are not translated correctly when they start with the decimal point, e.g., .372507410781367 becomes 372507410781367 in the c code. I do not know what the Algol standard says about this, but MARST does compile it correcly. (Also I do not know what compiler was used at CWI back then.) When I changed that constant to 0.372507410781367, the results became correct.

lukacsarpad commented 5 years ago

Slight correction, sorry. They are almost correct (I compared with Mathematica output, and only the first couple of digits are OK). Looking at the .c file, it seems that there are problems with real literals whenever they are in a not fully standard scientific form, e.g, 0.144882e-6 .12322e-6 but 1.1233e-6 is OK.

JvanKatwijk commented 5 years ago

Yes you are right. Looking into the code, I probably never realized that numerical denotations could start with a '.', That is corrected, but I am not sure whether I caught all kinds of denotation, not starting with a digit

The denotations starting with a dot start in the C output with a "0."

Op vr 7 dec. 2018 om 16:26 schreef lukacsarpad notifications@github.com:

Slight correction, sorry. They are almost correct (I compared with Mathematica output, and only the first couple of digits are OK). Looking at the .c file, it seems that there are problems with real literals whenever they are in a not fully standard scientific form, e.g, 0.144882e-6 .12322e-6 but 1.1233e-6 is OK.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/algol-60-compiler/issues/1#issuecomment-445266548, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwLfVf18aE-3rzsS9oOh6NeZSQCCzks5u2oiKgaJpZM4Y_nCc .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

lukacsarpad commented 5 years ago

Thank you very much. I have a launchpad PPA for ubuntu packages, but I cannot upload it with the same version number. I wanted to ask you if you would mind to bump the version number to reflect the changes. Also, I attach to this comment another version of ei.alg. The one now in examples produces incorrect results due to the changes I made to find why it did not work. In the new one, I also added a comment about the origin of the code. ei.txt

JvanKatwijk commented 5 years ago

I'll look into it tomorrow the two versions have as output 1 1.761958313 2 4.769059475 3 9.658866524 4 19.19291110 5 39.43747724 6 84.62850495 7 191.5047433 8 440.3798995 9 1037.878290 10 2492.228976

and 1 1.895117816 2 4.954234356 3 9.933832570 4 19.63087447 5 40.18527535 6 85.98976214 7 191.5047433 8 440.3798995 9 1037.878290 10 2492.228976 I noticed that in the second version you changed the *1000 etc, i.e. a run time operation, to extensions in the number denotations

If that is the only change (apart from eliminating a superfluous procedure), then - given that there is no difference in the Algol and C representations of the numbers - there is something with the conversion of the denotation with the e^xx extensions

I'll look into it tomorrow.

Btw, real funny to have to look back at a program written 15/16 years ago

Op vr 7 dec. 2018 om 20:54 schreef lukacsarpad notifications@github.com:

Thank you very much. I have a launchpad PPA for ubuntu packages, but I cannot upload it with the same version number. I wanted to ask you if you would mind to bump the version number to reflect the changes. Also, I attach to this comment another version of ei.alg. The one now in examples produces incorrect results due to the changes I made to find why it did not work. In the new one, I also added a comment about the origin of the code. ei.txt https://github.com/JvanKatwijk/algol-60-compiler/files/2658586/ei.txt

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/algol-60-compiler/issues/1#issuecomment-445346976, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwLH07AaqWNzRIVMHA0fJahPpZnYwks5u2sdegaJpZM4Y_nCc .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

lukacsarpad commented 5 years ago

I also found a mistake in the old version, where for some reason I changed 1e-12 to *0.12. I might have made other typos. The numerical constants in the new one are machine converted from the CWI original, apart from performing the division of two large (integer) constants, which overflow in C.

JvanKatwijk commented 5 years ago

changing line 84 back makes the output identical to what it was

Op vr 7 dec. 2018 om 21:42 schreef lukacsarpad notifications@github.com:

I also found a mistake in the old version, where for some reason I changed 1e-12 to *0.12. I might have made other typos. The numerical constants in the new one are machine converted from the CWI original, apart from performing the division of two large (integer) constants, which overflow in C.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/algol-60-compiler/issues/1#issuecomment-445359392, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwEW6NJXVDwzgvDP4DSC9r7ZKatHsks5u2tKdgaJpZM4Y_nCc .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

JvanKatwijk commented 5 years ago

I made a version 2.3

Op vr 7 dec. 2018 om 22:00 schreef jan van katwijk j.vankatwijk@gmail.com:

changing line 84 back makes the output identical to what it was

Op vr 7 dec. 2018 om 21:42 schreef lukacsarpad notifications@github.com:

I also found a mistake in the old version, where for some reason I changed 1e-12 to *0.12. I might have made other typos. The numerical constants in the new one are machine converted from the CWI original, apart from performing the division of two large (integer) constants, which overflow in C.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/algol-60-compiler/issues/1#issuecomment-445359392, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwEW6NJXVDwzgvDP4DSC9r7ZKatHsks5u2tKdgaJpZM4Y_nCc .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

lukacsarpad commented 5 years ago

Thank you! I uploaded my Ubuntu packages built from the sources here: https://launchpad.net/~lukacs-arpad/+archive/ubuntu/code-preservation