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

[Mark Morgan Lloyd]

Bernd Oppolzer wrote:
> 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.

I believe this sort of thing is also an issue when a function recurses.

> 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.

Anything that artificially limits function size, or forces the code 
generator to jump through hoops to work around architecture issues, is a 
problem /particularly/ when an external tool has automatically generated 
(Pascal) source. I'm not sure how many people use that technique these 
days but it was fairly popular in the era when Fortran was dominant, and 
there are still tools that generate C or Java source.

> 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.

[Nod] I believe that most of the above- as well as things like IEEE 
floating point support- is in late-model 390s and in the Hercules emulator.

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

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