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 ?
toggle quoted message
Show quoted text
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 ?
toggle quoted message
Show quoted text
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 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.
toggle quoted message
Show quoted text
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
toggle quoted message
Show quoted text
-----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 ? ?
toggle quoted message
Show quoted text
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."
|
Re: TXTLIB and Stack Question
On 2/26/20 11:02 AM, 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.
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?
The question is not are they in real memory immediately, but in
real memory when you need them. In that sense, it's better to
allocate as needed as not touched excess memory could get paged
out to disk and would have to be paged back in.?? Newly allocated
memory would come from the free pool (if the machine has such a
beast).
Of course on a lightly loaded machine like the 4361 (12MB real)
or most Hercules machines (16MB), free memory abounds and there is
very little paging.
--
Drew Derbyshire
GOD is REAL unless declared INTEGER.
|
Re: 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
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
On Wed, Feb 26, 2020 at 06:35 PM, Drew Derbyshire wrote:
Even if it doesn't do dynamic allocation, I'm surprised it doesn't get storage.? (I'd bypass getmain, that's OS emulation).
Noted - I will add this as a feature request
|
Re: TXTLIB and Stack Question
Last question should have read "once accessed"....
|
Re: 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
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
You might note that the offsets to the local variables in this generated code are quite high, at 88 and 92 - much longer than a save area would typically be (13 fullwords, or 72 bytes - note the STM 14,12,12(R13) at the beginning). So, although I have not looked at this in any detail at all, I would guess that the first part of the local variable area allocated on the "stack" is the save area (pointed to by R13), and above that are local variables for the routine. It might have been easier to figure out had the sample code called another routine and you could see the call sequence from the caller's perspective.
|
Re: 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.
¸é±ð²Ô¨¦.
toggle quoted message
Show quoted text
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
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
On Tue, 25 Feb 2020 at 22:38, Drew Derbyshire <swhobbit@...> wrote:
On 2/25/20 11:45 AM, rvjansen@... wrote:
As the mainframe did not have a stack until fairly late, I am curious
as to how that is handled in GCC on VM/370. Simulating a stack without
an instruction set to work upon it seems complex, if not to say, error
prone.
One does not require a stack pointer register to have a stack. One has
to have a convention of how you point to the stack.
That there was no stack in the normal call/return convention was the first thing that seemed odd when I started looking into assembler on the 370. 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. 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. R13 is the current save area. If you use a new save area (and put local
variables after it) for each new routine, you effectively have a stack
without using an extra base register. Interestingly I have just been reading about this convention. As described, on entry to a subroutine the caller would have set up R13 to point to somewhere (a save area) the called subroutine can store the general registers. If the called subroutine alters R13, for example it needs to call another subroutine, it would need to save it, for example in a save area it declares with DS. That doesn't make for reentrant code, though. So are we saying to switch to a stack-based convention means a subroutine that is written expecting there to be a stack would simply decrement (for a downward growing stack) or increment (for an upward growing stack) R13 by the space required for storing the registers? That means as long as control stays among routines written to work with the stack things are reenttrant. Subroutines using the non-stack convention could be called - the save/restore/return would still work, but that wouldn't be reenttrant. Non-stack routines could not called stack-based ones, though, because once R13 has been pointed to a small save area rather than a larger stack it can't simply be incremented/decremented. Or have I misunderstood this convention.
|
Re: TXTLIB and Stack Question
On 2/25/20 11:45 AM, rvjansen@... wrote: As the mainframe did not have a stack until fairly late, I am curious as to how that is handled in GCC on VM/370. Simulating a stack without an instruction set to work upon it seems complex, if not to say, error prone.
One does not require a stack pointer register to have a stack. One has to have a convention of how you point to the stack. R13 is the current save area.? If you use a new save area (and put local variables after it) for each new routine, you effectively have a stack without using an extra base register. Consider that Java uses a stack and IBM has had Java for years. -- Drew Derbyshire "Love means never having to say you're sorry." -- "Love Story"
|
cube1us