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

Bernd Oppolzer bernd.oppolzer at t-online.de
Tue Sep 3 00:15:19 CEST 2013


Am 02.09.2013 10:37, schrieb Mark Morgan Lloyd:
>
> That's obviously far friendlier to a language like Pascal than the 
> examples in most assembler-level treatises- I wonder how compatible it 
> is with the description of the Linux ABI informally at 
> http://linuxvm.org/present/SHARE99/S8139db.pdf ?
>
>
Some remarks regarding code generation:

if you have a language like C which doesn't support nested procedure 
definitions,
it's perfectly simple. You can reach the local (auto) variables using 
register R13, and
the parameters using R1. You only need another register to access the 
static data
and some kind of heap management to support malloc() etc., and that's 
about all.

With "classical" 360 machines, you had the problem that the offsets in 
the machine
instructions only were 12 bits long, so you could only address 4 k from 
the position
of a base register directly. That is, if your automatic data (of one 
procedure) was
larger than 4 k, you were in trouble. Data after the 4 k barrier had to 
be addressed
using two steps; first compute the address and the fetch the data - for 
example.

With new z-Arch instructions, this is no problem any more.

Same goes for the procedure code itself; PASCAL/VS (an old IBM compiler
of the 1980 years) limited the size of procedures to 8 k - which is some 
hundred
lines of source code. This, too, is no problem today any more, because, 
when
you use the new relative branches, you don't need base registers for the 
code area.

A language like Pascal, which allows the nesting of procedures and the 
access
of auto variables that are defined outside the local procedure (that is: 
in procedures
above the local procedure), you need to retrieve the stack frame of that 
procedure
first. This is done by walking up the chain of the save areas and load 
the base address
of the stack frame of the interesting procedure into another base 
register, different
from R13 (for example). This is a problem, that a C compiler doesn't 
have - but it's
well known to PL/1, too.

This all is very well known and can be derived from the other compilers 
that deal
with the z-Arch environment, for example the IBM commercial ones.

The z-Arch has evolved very much in the last 10 years, compared to 360 
and 370 days,
and this makes code generation and the life of compiler builders much 
easier.

Kind regards

Bernd





More information about the fpc-devel mailing list