<p>Am 03.09.2013 00:15 schrieb "Bernd Oppolzer" <<a href="mailto:bernd.oppolzer@t-online.de">bernd.oppolzer@t-online.de</a>>:<br>
> With "classical" 360 machines, you had the problem that the offsets in the machine<br>
> instructions only were 12 bits long, so you could only address 4 k from the position<br>
> of a base register directly. That is, if your automatic data (of one procedure) was<br>
> larger than 4 k, you were in trouble. Data after the 4 k barrier had to be addressed<br>
> using two steps; first compute the address and the fetch the data - for example.<br>
><br>
> With new z-Arch instructions, this is no problem any more.</p>
<p>FPC already supports some CPUs which have such restrictions as well. It's no real problem to split up single instruction branches/moves to do a calculation of an address before branching/moving. I'm doing this for example for the Coldfire m68k variant.</p>

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