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

[Bernd Oppolzer]

Am 03.09.2013 08:45, schrieb Mark Morgan Lloyd:
>
>> 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.

C supports recursion of functions, and it is without
problems possible with the scheme outlined above
and in the previous mails.

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

Agreed. But although the limit of 8 k per procedure seems
strange from todays point of view, there were significant
projects done with this compiler, for example the first TCP/IP stack
for the 370 platform in the early 1980s (inside IBM, in Pascal !!).

I still have lots of tools generating source code, for example PL/1 and C.
XML validator definitions, derived from XSDs (to speed up my XML parser) -
well, that's definitions, not executable code, but ocassionnally very 
large, if the
XSD is large - and database access routines ...

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