🚀 go-pugleaf

Dan Espen <dan1...@gmail.com> wrote:
> Peter Flass <peter...@yahoo.com> writes:
> 
>> Dan Espen <dan1...@gmail.com> wrote:
>>> I've done huge amounts of assembly programming and the instructions
>>> get the job done.  Issues with the base registers are easy to deal with
>>> once you figure out that each subroutine should have it's own base
>>> register, don't attempt to make all code addressible at once.
>>> 
>> 
>> My copy of Pugh is packed, but I think this was the intention. 4K can be a
>> bit small for a subroutine, but I think the designers expected programmers
>> to divide their programs into smallish subroutines. I don't think I've
>> written a lot of programs that needed multiple base registers. On the other
>> hand it's more complicated than it needs to be to save a base register and
>> load a new one - especially if you want to write reentrant code, where the
>> recommended technique requires OS intervention to get a free the savearea.
>> A hardware stack would have helped. and maybe one instruction to push a
>> register and load it with the address of the next instruction.
> 
> Not really that hard:
> 
>  LARL R11,SUB1   R11 <- subroutine address and base
>  BALR R14,R11   Go to subroutine
> 
> ...
> 
> SUB1 DS 0H
>  USING R11,*
>  STM   R2,R14,SUB1_SAVE
> do something
>  LM    R2,R14,SUB1_SAVE
>  BR  R14
>  DROP R11
> 
> Of course, there are always macros for the LARL/BALR and subroutine
> entry and exit so it looks like:
> 
>  XBAL SUB1
> 
> ...
> 
> SUB1 ENT
>  do something
>  LEAVE
> 
> The macros push the subroutine name
> into a macro array for later automatic save area generation.
> 
> I'm never clear on what happens when you exceed
> the limits of a hardware stack.
> 

Sure, now you have LARL. You can also preallocate a largeish storage area
as a stack to grab saveareas off, to avoid GETMAIN/FREEMAIN.

-- 
Pete