On Fri, Feb 28, 2020 at 06:23 PM, Drew Derbyshire wrote:

For reentrant code, the classic (memory limited) IBM way would to be allocate what you need (including the save area) for each routine (stack frame) upon entry and release upon exit.

Sounds very slow! :-)

Anyway, for VM/370 I will be kind of up for making the stack size configurable (on a per module basis) and dynamically allocated from the heap. Dynamically growing the stack is much too hard ...

Adrian

开云体育

On Fri, Feb 28, 2020 at 01:43 AM, Drew Derbyshire wrote:

The limits of 4K addressability and the need for stack frame pointers imposes most of the same overhead.? The primary (perhaps only) only additional overhead would be actual allocation/freeing of memory.

Can you please explain the 4k addressability point, I don't know what that means. Thank you.

Refer to page 21-22 of ; the short answer is because any instruction using a base register and a displacement (which is 12 bits) can only access 4095 (2**12 -1) bytes higher than the base register.? You can of course, use additional registers for more 4096 byte increments or load the raw address into a register using an address constant.?

If you think about it, unless you're allocating large strings or *huge* structures directly on the stack, you won't use more than 4096 bytes on the stack in one routine anyway.? (Consider how in C++, std::string has the metadata on stack but the actual string data on the heap.)

As for the overhead, the big problem is having a really efficient way to determine (each time you move the stack pointer) if you have run out of stack space.

A single instruction to compare the addresses of the end of the current stack and the end of allocated storage is sufficient.

For reentrant code, the classic (memory limited) IBM way would to be allocate what you need (including the save area) for each routine (stack frame) upon entry and release upon exit.

You might look at how IBM PL/I does it.? The LCM+L 4361 has both the PL/I (F) and PL/I Optimizing compilers.

-ahd-

-- 
Drew Derbyshire

"My parents taught me what life was about
 So I grew up the type they warned me about
 They said my friends were just unruly mob
 And I should get haircut and get a real job!"
                                        -- "Get a Haircut", Avery and Birch

On Fri, Feb 28, 2020 at 10:40 AM, Steven Fosdick wrote:

360/370 instructions that access memory are base register+displacement
or base register+index register+displacement. The displacement is 12
bits so can only address 4K.

But if R13 is being used as a stack pointer and moves with each call
and return that surely means that the amount of stack any one
subroutine can use for local variables is limited to 4K but the stack
as a whole could be much bigger.

Thanks - I was not aware that I had a 4k limit for local variables in a function, so useful!

Interestingly (?) the classic Mac had a complex heap scheme whereby the os could move memory, and applications had to use pointers to pointers (handles) to access heap variables. Hence the phrase dangling handles, which always made me smile, except when I was debugging!

Windows did something similar too. I am not aware of any
implementation of such a scheme where, in a language such as C, it
remains hidden from the programmer by the compiler. That means both
user programs and library code would need to be written to work with
it.

On Fri, 28 Feb 2020 at 06:53, adriansutherland67
<adrian@...> wrote:

Can you please explain the 4k addressability point, I don't know what that means. Thank you.

360/370 instructions that access memory are base register+displacement
or base register+index register+displacement. The displacement is 12
bits so can only address 4K.

But if R13 is being used as a stack pointer and moves with each call
and return that surely means that the amount of stack any one
subroutine can use for local variables is limited to 4K but the stack
as a whole could be much bigger.

On Thu, Feb 27, 2020 at 06:45 PM, Dave Wade wrote:

A pointer to this table is stored in the CMS Nucleus in low core

Thanks for the details David, useful.

One correction, in the updated version of GCCLiB, the guys determined the base address of the table by dynamically asking RESLIB on startup which is much more cunning.? It leaves open the possibility of dynamically loading it if it's not there, we probably won't bother but hey!

In fact they showed the way, we will use the same scheme to allow access to REXX variables which we will handle with a separate resident library.

On Fri, Feb 28, 2020 at 01:43 AM, Drew Derbyshire wrote:

You can't move the stack because pointers to local variables must remain valid as they can be passed to lower level subroutines.

To do this GCC would need to be using a base register for all memory access (I.e an offset from a register). I don't know if it does, I suspect not.? Interestingly (?) the classic Mac had a complex heap scheme whereby the os could move memory, and applications had to use pointers to pointers (handles) to access heap variables. Hence the phrase dangling handles, which always made me smile, except when I was debugging!

On Fri, Feb 28, 2020 at 01:43 AM, Drew Derbyshire wrote:

The limits of 4K addressability and the need for stack frame pointers imposes most of the same overhead.? The primary (perhaps only) only additional overhead would be actual allocation/freeing of memory.

Can you please explain the 4k addressability point, I don't know what that means. Thank you.

As for the overhead, the big problem is having a really efficient way to determine (each time you move the stack pointer) if you have run out of stack space.?

I am not too worried about allocating or freeing memory from time to time and having complex logic to handle the jump from one bit of the stack in one place and another somewhere else because this will be relatively infrequent. After all each chunk of the dynamic stack can be large.

But you don't want to do that each function call. You need something really quick to check if the pointer is about to run out of the chunk of memory it is using. (Shrinking is possibly easier, but you need something fast here too). So does that mean we would reserve another register to hold the end of the chunk, and have to compare the value of the two registers each time you enter a function? Impact on performance? Etc ...

On 2/27/20 9:53 AM, Dave Wade wrote:

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Drew
Derbyshire
Sent: 27 February 2020 01:05
To: [email protected]
Subject: Re: [h390-vm] TXTLIB and Stack Question

On 2/26/20 12:02 PM, adriansutherland67 wrote:

Traditionally on other simple/old platforms you would load your
program in low memory address, have the head (dynamic memory) low as
well, and put your stack to start at the top of memory working
downwards (and hope they never met!). So actually for CMS we should go
the same - but for small programs (e.g. cms subset) you would want the
stack part of the program.

No. Allocate what you need and use it. CMS doesn't spawn a new address
space for each child (EXECs, transient programs), so grabbing all available
memory is a really bad idea.

You don't really have much choice. You can't move the stack because pointers to local variables must remain valid as they can be passed to lower level subroutines.

Tell Java it can't move stuff around.? :-)

(I'm really saying it depends on how much indirection your compiler is willing to do.? In C with its raw pointers, not much.)

Managing a discontigous stack is possible, but I think it might make subroutine linkage slow.

The limits of 4K addressability and the need for stack frame pointers imposes most of the same overhead.? The primary (perhaps only) only additional overhead would be actual allocation/freeing of memory.

--
Drew Derbyshire

Windows Vista, the chastity belt of operating systems.

I should all the stuff in the non-resident GCCLIB is to get around TXTLIB restrictions.
The way we normally use CMS is to issue a "LOAD" command which loads a TEXT deck or decks and resolves missing external references from TXTLIB or TEXT files.
It loads from its origin upwards, so everything loaded sits as nice solid lump from 2000 (is that the right number of zeros) upwards.
We then use GENMOD which saves the loaded lump do disk. To run the program we just type the name of the module.
So when its run no TEXT or TXTLIB is necessary. The program is copied from disk to store and executed.

The resident library load process works as follows...

1). Use RESLIB to Load the resident library into CMS in high memory. RESLIB marks this memory as "SYSTEM" so it does not get released by other programs. One of the routines contains a jump table to the other routines. A pointer to this table is stored in the CMS Nucleus in low core. The advantage of just loaded them as pile of TEXT decks is that you know what has been loaded. You can't pick up any extraneous crap because there is a subroutine name clash and a TXTLIB is globaled elsewhere. I can't see that functionally using a TXTLIB is any different because the only way to access a routing is via the jump table, and so if something isn't accessible via the jump table.

2) when a program wants to use the resident library it is linked with the STUB library. The stub library MUST contain entry points to every external in the resident library that a "C" program is permitted to call. If you get missing routines because and have to add other stuff from GCCLIB TXTLIB then you are loading things those things in low memory with the module. This may or may not be desirable, but if the routine is self contained its ok. I can't think of anything like that so I would treat as an error. We then GENMOD our program which saves our low memory to disk.

3) When we run our MODULE no TXTLIB resolution is performed. If our program calls a GCCLIB routine, it calls the stub routine, which picks up a pointer to the jump table and branches to that location.

So generally, there is no TXTLIB processing when programs are run. One exception is BREXX because we I explained in the past we want that loaded high as well. In this case even though RESLIB does the loading it does not re-use any entry points from other routines. The comms from BREXX to the library as above.

Dave

开云体育

On Thu, Feb 27, 2020 at 05:10 PM, Dave Wade wrote:

SORRY TO SHOUT BUT THERE ARE NO ADDRESS SPACES IN CMS. YOU SHOULD NOT USE GETMAIN IN GCCLIB. THE WHOLE POINT OF GCCLIB IS TO AVOID OS EMULATION

?

Dave

NOTED :-)

开云体育

开云体育

OK, thats fair. Mine doesn’t either, but it is gathering dust.

Rene,
But my p390 doesn't in 370 mode...
Dave

开云体育

On 2/26/20 12:02 PM, adriansutherland67 wrote:

Traditionally on other simple/old platforms you would load your program in low memory address, have the head (dynamic memory) low as well, and put your stack to start at the top of memory working downwards (and hope they never met!). So actually for CMS we should go the same - but for small programs (e.g. cms subset) you would want the stack part of the program.

No.? Allocate what you need and use it.? CMS doesn't spawn a new address space for each child (EXECs, transient programs), so grabbing all available memory is a really bad idea.

--
Drew Derbyshire

"OSI: Same day service in a nano-second world." -- Van Jacobson

开云体育

On Wed, Feb 26, 2020 at 07:02 PM, Doug Wegscheid wrote:

Problem with getting more stack on-demand is that you are not guaranteed that your getmained storage is contiguous with your e during stack.

And that would be a nightmare and quite slow (each function call would have complex checks).

With only 4K addressable per base register, you have complexity even if you allocate it all up front.? Like a stack machine, you'll need a pointer to each frame anyway.

Other option is to copy the old stack to the new space when resizing.

I'm remind of how old Java garbage collection used to brings to screeching halt when running.

Again hardly ideal as it fragments memory.

The stack will grow and shrink.? A bigger concern would be heap fragmentation.

-ahd-

-- 
Drew Derbyshire

"This message brought to brought to you by the letters O, S, and the"
 number 2."