[fpc-devel] Re: System 370: Episode 3. Addressing and it's limits Part One!
stevie at collector.org
Fri Feb 10 22:06:59 CET 2012
Mark Morgan Lloyd wrote on Fri Feb 10 21:20:15 CET 2012
>>> If Hercules is configured as an S/390 to keep the guest operating system
>>> (e.g. Linux) happy, is it possible to validate that a binary is
>>> completely safe to run on an S/370, i.e. contains no 390-specific features?
>> I'm not exactly clear on what you are asking. You could turn off the 390
>> features on Hercules and see if it crashes, or you could ensure you don't
>> generate thme by using some compiler switch, or you could remove the macros
>> required for the IBM Assembler to support the mods, they will cause assembly
>> errors. Or what ...?
> But assuming that an initial port is to Linux, you need Hercules to
> provide S/390 features or the operating system won't run. The way I read
> it, if you're also targeting classic operating systems such as VM/370
> then the only way to prove that the code generation is 370-safe is to
> run the code on a (simulated) 370: there's no way of testing compliance
> at an earlier stage.
Hercules provides the S/390 features for Linux, but we don't have to use them.
S/370 is a subset of S/390, that will run quite happily on S/390 processors.
The only requirement for S/390 extensions is gas. But gas doesn't support
USING and is a waste of space for our requirements. (This may not apply
to the version of gas supplied with OS/380)
There is nothing provided in the extensions that we cannot achieve without them,
sometimes it may be more aggro, but we can still do it. We could, if we were
bored and had nothing better to do, write macros for the System/370 assembler
to support the S/390 extensions on a base "real-iron" box.
Anyway, assuming that Linux/390 is the target. There is no way to prove
compliance of the initial port until we are ready to run on Linux/390. At
some stage, you have to bite the bullet. We also have to modify the RTL,
even for Linux/390.
More information about the fpc-devel