[fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....

[Mark Morgan Lloyd]

Steve wrote:
> Mark Morgan Lloyd wrote
> 
>> > Otherwise we also rely on external tools (mostly the GNU linker)
>> > here. So as a first step you'd choose the approach of using an
>> > external assembler and linker, because simply calling a third party
>> > utility is easier than completely implementing an internal assembler
>> > and linker.
>>
>> With the caveat here that as I understand it experienced IBM programmers
>> avoid the GNU assembler like the plague, since it doesn't have anything
>> like the sort of macro facilities they're used to. By implication, that
>> would imply that they prefer to avoid the GNU linker and related tools
>> as well.
> 
> There is a problem inherent in this discussion; zArch is not one 
> environment!
> It's one architecture supporting multiple operating systems, much like the
> 386/486/586/686 etc supports Linux or DOS or OS/2 or Windows (all 37 
> versions)
> etc. zArch has MVS (in all it's varieties) VM, DOS, LINUX, MFT, MVT, 
> MUSIC/SP,
> and loads of other more niche stuff. In addition to all this, later 
> versions of
> MVS supply a POSIX compliant shell called OMVS. GNU anything is 
> available in
> hardly any of these environments even if we can handle the brain-dead 
> assembler.

GCC plus the basic utilities are definitely ported to VM/370 and 
MUSIC/SP (i.e. I've run them), and as far as I know to the others. In 
all cases possibly subject to memory restrictions, i.e. might need more 
than the standard 16Mb supplied by older operating systems for large 
jobs (that's where the /380 patch to Hercules comes into it).

>> > Just to name a few: you'll need to get parameter passing for functions
>> > correctly
> 
>> Which leads to another issue: the 370 is a register-based system without
>> a stack as understood today. Parameters are mostly passed in registers,
>> but this is largely hidden since supervisor calls etc. are usually
>> hidden in macros.
> 
> I am an MVS person so I can't speak for the other lot but parameter passing
> is mostly done in storage. The standard linkage conventions used allow for
> two 32-bit signed or unsigned integers (64-bit in later models). Anything
> else is passed in a storage area pointed to by register 1. Where this 
> storage
> area comes from is complex and variable. My guess that the other IBM 
> systems
> have similar models. A further guess is that Linux based code allocates an
> area of storage, points a register at it, write a couple of mickey mouse
> macros and bingo, a stack.

Don't guess, see http://wiki.lazarus.freepascal.org/ZSeries which apart 
from anything else has links to the original GCC implementation notes 
which in part determine what architecture variants Linux supports. 
However there also appear to be later ports which support older CPU 
variants, see link below.

>> My own feeling is that it would be best to start targeting a late-model
>> 390, which does have a stack etc., and to use the standard GNU assembler
>> and linker (as and ld)/initially/  targeting Linux. Any other
>> combination (i.e. a proprietary assembler etc. with an antique MVS as
>> target) is going to cause nothing but grief, since it makes it very
>> difficult for developers skilled with FPC but not with IBM mainframes to
>> give any practical help.
> 
> Late-model 390's have a stack, but not as you know it. It's not something
> you can go around lobbing arbitrary data at. It is reserved for data saved
> during subroutine linkage using the appropriate hardware instruction 
> (Branch
> and Stack). This includes various register sets, PSW status info etc) 
> and an
> additional two 32-bit signed or unsigned integers (64-bit in later models).

The examples at 
http://wiki.lazarus.freepascal.org/Assembler_and_ABI_Resources#zSeries_.28S.2F390.29 
show a significant simplification of the code when a newer architecture 
is specified.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]