[fpc-devel] Re: fpc-devel Digest, Vol 93, Issue 57
Mark Morgan Lloyd
markMLl.fpc-devel at telemetry.co.uk
Mon Jan 30 19:25:02 CET 2012
steve smithers wrote:
>>> michael.vancanneyt at 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 at 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
Code generation complete
0 1>markMLl at pye-dev-07f:~/hello_world$ ls -lt
-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 at pye-dev-07f:~/hello_world$ ./hello
That's on a system which describes itself as
0 1>markMLl at 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
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
More information about the fpc-devel