Keyboard Shortcuts
Likes
- H390-Vm
- Messages
Search
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: 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. -- 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+displacementThanks - 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 coreThanks 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:
Tell Java it can't move stuff around.? :-)-----Original Message-----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. (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.
toggle quoted message
Show quoted text
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----- |
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 ? 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:
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. |
Re: TXTLIB and Stack Question
toggle quoted message
Show quoted text
-----Original Message-----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. Dave "OSI: Same day service in a nano-second world." -- Van Jacobson |
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:
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. |
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? ?
|
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: |
Re: TXTLIB and Stack Question
Rene,
toggle quoted message
Show quoted text
But my p390 doesn't in 370 mode... Dave -----Original Message----- |
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 ? On Tue, Feb 25, 2020 at 04:20 PM, gdblodgett wrote:
I fear that is me! |
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: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." |