开云体育


Re: TXTLIB and Stack Question

 

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


Re: TXTLIB and Stack Question

 

开云体育

On 2/27/20 10:53 PM, adriansutherland67 wrote:
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


Re: TXTLIB and Stack Question

 

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!


Re: TXTLIB and Stack Question

 

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.


Re: TXTLIB and Stack Question

 

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.


Re: TXTLIB and Stack Question

 

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.


Re: TXTLIB and Stack Question

 

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!


Re: TXTLIB and Stack Question

 

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


Re: TXTLIB and Stack Question

 

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.


Re: TXTLIB and Stack Question

 

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

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Dave Wade
via Groups.Io
Sent: 27 February 2020 17:53
To: [email protected]
Subject: Re: [h390-vm] TXTLIB and Stack Question



-----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.
Managing a discontigous stack is possible, but I think it might make
subroutine linkage slow.



--
Drew Derbyshire
Dave

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





Re: TXTLIB and Stack Question

 

开云体育

Dave,?

The "getmain" usage in this thread is my fault. I had a senior moment and couldn't recall the native macro name and used "getmain" instead as I felt that it is a widely recognized for storage/memory management.? The CMS native macros are DMSFREE/DMSFRET.

Please accept my apologies for any confusion it caused.

Gary



Sent from my T-Mobile 4G LTE Device


-------- Original message --------
From: Dave Wade <dave.g4ugm@...>
Date: 2/27/20 12:14 PM (GMT-05:00)
Subject: Re: [h390-vm] TXTLIB and Stack Question

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

?

From: [email protected] <[email protected]> On Behalf Of Doug Wegscheid
Sent: 26 February 2020 21:21
To: [email protected]
Subject: Re: [h390-vm] TXTLIB and Stack Question

?

I'm not sure that copying the stack to a new location in the address space will work, how do you know what else is accessing the stack.

?

Putting dynamic memory low (growing up) and stack high (growing down) is pretty common...

?

On Wednesday, February 26, 2020, 3:02:20 PM EST, adriansutherland67 <adrian@...> wrote:

?

?

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). Other option is to copy the old stack to the new space when resizing. Again hardly ideal as it fragments memory.

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

Anyway we can have fun with options!

For?


Re: TXTLIB and Stack Question

 

-----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.
Managing a discontigous stack is possible, but I think it might make subroutine linkage slow.



--
Drew Derbyshire
Dave

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



Re: TXTLIB and Stack Question

 

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 :-)


Re: TXTLIB and Stack Question

 

开云体育

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

?

From: [email protected] <[email protected]> On Behalf Of Doug Wegscheid
Sent: 26 February 2020 21:21
To: [email protected]
Subject: Re: [h390-vm] TXTLIB and Stack Question

?

I'm not sure that copying the stack to a new location in the address space will work, how do you know what else is accessing the stack.

?

Putting dynamic memory low (growing up) and stack high (growing down) is pretty common...

?

On Wednesday, February 26, 2020, 3:02:20 PM EST, adriansutherland67 <adrian@...> wrote:

?

?

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). Other option is to copy the old stack to the new space when resizing. Again hardly ideal as it fragments memory.

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

Anyway we can have fun with options!

For?


Re: TXTLIB and Stack Question

 

开云体育

Doug,

CMS knows nothing of virtual. It runs DAT off. CP handles all that magic stuff. So if you do a GETMAIN nothing gets paged in or out until you access the GETMAINed store.

Dave

?

From: [email protected] <[email protected]> On Behalf Of Doug Wegscheid
Sent: 26 February 2020 19:03
To: [email protected]
Subject: Re: [h390-vm] TXTLIB and Stack Question

?

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

?

If you have address space allocated for excess stack, do the excess pages of the stack end up in real memory immediately, or do they only exist in real memory once allocated?

?

On Wed, Feb 26, 2020 at 1:35 PM, Drew Derbyshire

<swhobbit@...> wrote:

On 2/26/20 3:20 AM, rvjansen@... wrote:
> I see, and thanks for the explanation. Some thoughts: 32k words is quite a chunk for VM/370, but quite small for a serious program.

It's good for a 1972 IBM machine, but not good for even a 1985 24-bit
IBM machine; the LCML+L 4361 (a midrange machine at best) for example
has 12 Meg real, and by default users have a 4M virtual machine (and can
go higher).

> I would see the value of a macro approach to have a smaller initial stack, but to check size and getmain more if needed.
>
Even if it doesn't do dynamic allocation, I'm surprised it doesn't get
storage.? (I'd bypass getmain, that's OS emulation).

--
Drew Derbyshire

? Harris's Lament: All the good ones are taken




Re: TXTLIB and Stack Question

 

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

On 27 Feb 2020, at 17:47, Dave Wade <dave.g4ugm@...> wrote:

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


Re: TXTLIB and Stack Question

 

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

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
rvjansen@...
Sent: 26 February 2020 11:21
To: [email protected]
Subject: Re: [h390-vm] TXTLIB and Stack Question

I see, and thanks for the explanation. Some thoughts: 32k words is quite a
chunk for VM/370, but quite small for a serious program. I would see the
value of a macro approach to have a smaller initial stack, but to check size and
getmain more if needed.

Not that I am a fan of anachronism, but Hercules does have all the modern
stack instructions.

搁别苍é.

On 26 Feb 2020, at 02:50, Drew Derbyshire <swhobbit@...>
wrote:

?On 2/25/20 4:37 PM, Steven Dickson wrote:
I don't think there is any magic about stack-oriented instructions,
though. On a processor that has a descending stack PUSH is just a
store and a decrement combined and thus can be simulated by writing
the store and decrement separately, likewise POP is a load and
increment.
Correct. Put it in a macro and you're done.
The stack based return can be done with a load and then
branch-to-address-in-register. The only one that is a bit special is
the stack based CALL - writing that as separate instructions would
give the wrong return address is one used a regular branch but BALR
is fine, that captures the return address in a register and then in
the called subroutine wants to store it on a stack it can.
Again. Do a macro.
Or have I misunderstood this convention.
No, you have a reasonable understanding.


--
Drew Derbyshire

". . . Well we made a promise Blood brothers on a summer's night
We swore we'd always remember With a vow to defend
No retreat baby, no surrender No retreat baby, no surrender . . ."
-- Bruce Springsteen





Re: TXTLIB and Stack Question

 

开云体育

CMS general loads the primary user program at x’20000’ and storage is cleared at the END of the primary program running at the command level.

?

Mark

?

?

From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: Tuesday, February 25, 2020 8:39 AM
To: [email protected]
Subject: Re: [h390-vm] TXTLIB and Stack Question

?

On Tue, Feb 25, 2020 at 04:20 PM, gdblodgett wrote:

I will defer to the current maintainers

I fear that is me!

Local is good - its what I had assumed.?

Last question for a bit (promise) - does CMS generally load programs to the same address and not clear up memory between program launches? I just want to get to the bottom of how one run of a program leaves stuff behind that interferes with the next program.


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

--
Drew Derbyshire

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


Re: TXTLIB and Stack Question

 

开云体育

On 2/26/20 12:02 PM, adriansutherland67 wrote:
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."