mikanystrom-intel
commented
1 month ago In the above, when I wrote "integrated" backend I meant the gcc-based "native" backend for those who didn't follow. I don't have anything against the C backend but I have had trouble getting it to work 100% of the time, plus it does seem to lead to some performance loss (am I wrong about that? Curious if anybody has done any testing on it. Part of the reason I use M3 is for the performance gain over, say, Python, or even over Java. 3X over Java was normal back in the day, not sure about now.)
mikanystrom
VictorMiasnikov
Not sure if I am getting through to m3devel (I may be using the wrong email address), so I will repeat my issues here.
Hello everyone,
I am trying to get the compiler working, again. And as usual, I am unable to really get things working properly.
Does anyone in m3devel-land know how to bootstrap the compiler properly with the current git head?
In particular, does anyone know how to get the integrated backend working?
I have been trying to use the C backend on our internal Intel code, which I am eager to publish, but not till it builds with the git head!
I am running into the following issues...
Starting with d5.11.0 from a few years ago (what we have installed at Intel) I took the current sources and was able to hack things to get
./upgrade.py
to work (mainly by building the libs under m3-sys in a funny order manually so the compiler would build because it was relying on changes in the other libs...) I suspect there is a better way to do it than that.
I then was able to build do-cm3-all.py buildship
but I had to change the python code because it has python 2-isms, I think. (os.path.walk... in two places). In any case all built and I was able to play Tetris.
But getting at the Intel code was harder.
Here is what happens with the compiler I have as built.
I have the following little test program:
MODULE Main; IMPORT IO; IMPORT Math; IMPORT Fmt;
VAR x, y : LONGREAL := 1.0d0; z : LONGREAL := Math.modf(x, y);
t : LONGREAL := Math.cosh(x);
BEGIN
IO.Put("Hello, World!\n");
IO.Put("x = " & Fmt.LongReal(x) & "\n");
END Main.
(the reason for it will become clear...)
sccf034907> /nfs/site/home/mnystroe/char8/cm3-d5.11.0/bin/cm3 -x --- building in ../AMD64_LINUX ---
unable to read ../src/m3overrides, options "-override" and "-x" ignored. new source -> compiling Main.m3 "../src/Main.m3", line 8: warning: not used (z) "../src/Main.m3", line 10: warning: not used (t) 2 warnings encountered * PARALLEL BACK-END BUILD, M3_PARALLEL_BACK = 20 cm3cg: fatal error: bad M3CG version stamp (0x120), expected 0x110 compilation terminated. -> linking testm3 _m3main.o: In function
main': /nfs/site/disks/zsc9_fwr_sd_001/mnystroe/testm3/AMD64_LINUX/_m3main.cpp:53: undefined reference toMain_M3' collect2: error: ld returned 1 exit status m3_link => 256 linker failed linking: testm3 Fatal Error: package build failed sccf034907>I take it this is a failure of the integrated backend. So I try the C backend instead:
sccf034907> /nfs/site/home/mnystroe/char8/cm3-d5.11.0/bin/cm3 -DM3_BACKEND_MODE=C -x --- building in ../AMD64_LINUX ---
unable to read ../src/m3overrides, options "-override" and "-x" ignored. new source -> compiling Main.m3 "../src/Main.m3", line 8: warning: not used (z) "../src/Main.m3", line 10: warning: not used (t) 2 warnings encountered **** PARALLEL BACK-END BUILD, M3_PARALLEL_BACK = 20 -> linking testm3 Main_m.o: In function
Main_M3': /nfs/site/disks/zsc9_fwr_sd_001/mnystroe/testm3/AMD64_LINUX/../src/Main.m3:10: undefined reference tom3_modf' collect2: error: ld returned 1 exit status m3_link => 256 linker failed linking: testm3 Fatal Error: package build failed sccf034907>Basically, with the C backend I "lose" the following:
Math.cabs Math.frexp Math.modf
and I am guessing this has to do with their "odd" signatures, but am not sure:
EXTERNAL> PROCEDURE cabs (z: Complex): LONGREAL; TYPE Complex = RECORD x, y: LONGREAL END; ( returns sqrt (z.xz.x + z.yz.y) )
(---- Floating point representations ----)
<EXTERNAL> PROCEDURE frexp (x: LONGREAL; VAR exp: int): LONGREAL; ( returns a value y and sets exp such that x = y 2^exp, where ABS(y) is in the interval [0.5, 1). *)
<EXTERNAL> PROCEDURE modf (x: LONGREAL; VAR(OUT) i: LONGREAL): LONGREAL; ( splits the argument "x" into an integer part "i" and a fractional part "f" such that "f + i = x" and such that "f" and "i" both have the same sign as "x", and returns "f". Although "i" is a LONGREAL, it is set to an integral value. )
Something is going wrong in the C-based compiler here and the symbols are nowhere to be found. I'm not sure exactly what the compiler is trying to do. Some sort of funky interfacing to get around the VAR parameter and structure passing?
I would prefer to use the integrated backend because I think it runs faster and possibly generates better code, but am OK with using the C-based backend. Right now, neither works.
But all symbols must be linkable, or things won't work. This is because the Scheme system generates call stubs for all symbols in an interface, so since I want to access Math through Scheme, I need to be able to link against all the symbols that appear in that interface.\
Can anyone shed any light on the situation here?
P.S. I also ran into an issue that the Swap interface had changed. Swap.endian was replaced by Swap.GetEndian(). This breaks existing code, but OK it's a (relatively) minor issue...