steve smithers wrote:
michael.vancann...@wisa.be wrote the following on 30/01/12 17:35
I had in mind the following scenario:
1) Somehow we build - using cross-compilation - a first version of the
compiler that actually runs on the 370. This binary is transferred to a
370 machine.
I haven't got that far in my notes yet but... Cross-compilation - yes.
Building a 370 binary on Linux or Windows - Well you can if you want but...
Transfer binary to a 370 machine - Whew. This is problematic.
It's not any problem to move the binary itself, but there is more required
than the binary itself in order to produce an executable load module on any
OS version. (I can't comment on VM or DOS cause they are a mystery to me).
An OS binary consists of more than the binary and I know of no way to build
that information on Linux or Windows.
That's not the case when the target is Linux: as with all distreaux and
variants, the program compiles to a single file:
0 1>markMLl@pye-dev-07f:~/hello_world$ pascal-xsc hello.p
environment file /usr/local/p-xsc/sys/p88.env found.
Compiling hello.p with PASCAL-XSC version T3.62 dated 07.12.05
(C) Copyright University of Karlsruhe 1991-1999
(C) Copyright University of Wuppertal 2000-2005
importing module /usr/local/p-xsc/sys/stdmod.mod
FILE: hello.o
Analysis complete
Code generation complete
0 1>markMLl@pye-dev-07f:~/hello_world$ ls -lt
total 108
-rwxr-xr-x 1 markMLl markMLl 100118 Jan 30 18:17 hello
-rw-r--r-- 1 markMLl markMLl 68 Jan 30 18:16 hello.p
0 1>markMLl@pye-dev-07f:~/hello_world$ ./hello
Hello, World!
That's on a system which describes itself as
0 1>markMLl@pye-dev-07f:~/hello_world$ cat /proc/cpuinfo
vendor_id : IBM/S390
# processors : 2
bogomips per cpu: 629.00
features : esan3 stfle msa ldisp eimm dfp
processor 0: version = 00, identification = 000069, machine = 9672
processor 1: version = 00, identification = 100069, machine = 9672
However I am aware that various mainframe OSes- not limited to IBM-
insist on "blessing" executables before they can be run.
I would very strongly suggest cross-compile fpc on Linux/Windows using a version
that emits, not gas assembler but 370 assembler. I will be talking about gas vs
370 assembler later. The assembler output can be in ASCII or EBCDIC as rvmartin
said it's just a character encoding. The advantage is that you only need to
upload a text file(s). Feed it into the OS assembler and link programs and you
have a 370 load module.
We look forward to your notes. My understanding is that at least one
variant of FPC (the one targeting x86) can use multiple assembler
notations, so the exact format of the assembly source might turn out not
to be a problem. More of a problem would be is 370 Assembler conventions
turned out to be incompatible with FPC code generation.
2) The sources of the compiler and RTL are transferred to the 370.
I assume that after the file transfer, the sources are still in ASCII format ?
It depends on the options you use on your file transfer program, but I would
convert to EBCDIC here.
3) At that point the compiler can try to recompile itself on the 370
machine.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
