|
First progress (remembering I am keen to get gcclib fit for purpose asap so I can play rexx): -? GCCLIB global variables (e.g. stdin) working and being rolled out. - About to move to RESLIB only? - perror() implemented, glueing in stdio
- Will add workaround to cmscommand calltype 11
- Lots of stdio issues raised (a list always helps)
- About to glue in the famous dlmalloc() to give us best in class memory allocation (C programs should not directly use OS level memory management ... performance). E.g.?
- Move the last functions to RESLIB, see if anything critical needs implementation (e.g. registering exit functions are missing, but who trusts them anyway!)
The biggest architectural hole is the stack. About 120k allocated at startup. Bound to be too small or too big!?
So we need to use a split stack, or stacklets, see link below (obviously triggered by their problems with multithreading) for some insight in thinking. We are different but prior art etc.
Different options, and we have the advantage that stackframes don't have to be contiguous on s/370.
For performance the ideal situation is that it mostly works like now except with an extra check to see if we are out of space in the current stack segment. This check must be fast.
If we are out of space we can call a c function to make a new segment, handle linked lists etc. A problem is that will need stack space. I am considering having a buffer space (as per the link), or having a separate fixed stack for stack management.
Anyway ... the question is the fast stack space check. The obvious way is to use the reserved word 1 on the stackframe. On the basis that.
- PL/I and Fortran uses it (although I have never found anything explaining what for) so why not C!
- Assembler programmers know to avoid it!
- Is anyone going to try and link PL/I and C programs together? Of course not!
- Fastest performance.
- No other sensible options!
So this is a call for (and I appreciate negative feedback in the past) suggestions, objections, and I really hope support for this approach.
Any REXX?needs really good memory management in the underlying C library ...
Note to self ... check long jumps ...
|
- Is anyone going to try and link PL/I and C programs together? Of course not! Would that rule out calling Rexx external functions written in PL/I? 搁别苍é.
|
On Sun, Apr 5, 2020 at 09:30 AM, rvjansen@... wrote:
Would that rule out calling Rexx external functions written in PL/I?
It doesn't rule out calling PL/I programs via SVC 202 which, I think, is the way rexx external functions would need to be packaged (in sum, modules). In any case does PL/I on VM/370 support EPLIST (i.e. has there been a mod on the 6 pack). If there are PL/I programmers out there who would like to do a mod to support the 6 word EPLIST then we would be in business :-) Otherwise. 8 char parameters and an int return only ...
|
From what I remember the free PL1 is a mess. It usually works but I don’t think any one has made serious use of it. Pretty sure assembler support routines could be added to retrieve the data from an extended PLIST. ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 05 April 2020 10:44
To: [email protected]
Subject: Re: [h390-vm] Dynamic / split stacks (gcclib)? On Sun, Apr 5, 2020 at 09:30 AM, rvjansen@... wrote: Would that rule out calling Rexx external functions written in PL/I?
It doesn't rule out calling PL/I programs via SVC 202 which, I think, is the way rexx external functions would need to be packaged (in sum, modules).
In any case does PL/I on VM/370 support EPLIST (i.e. has there been a mod on the 6 pack). If there are PL/I programmers out there who would like to do a mod to support the 6 word EPLIST then we would be in business :-)
Otherwise. 8 char parameters and an int return only ...
|
It being IBM PLI/F it must have seen some serious use in the 1966-1971 era - don’t let the old Hursley geezers hear you ;-)
In the 80’s-90’s I only did some voodoo programming with it - the later optimizing’ version; we had an ‘unofficial’ (but IBM sanctioned) compiler we needed for some early dynamic SQL things. It looked a lot like Rexx as I remember. I thought of using it for some of the VM extensions - anything to avoid C, also for me.
toggle quoted message
Show quoted text
From what I remember the free PL1 is a mess. It usually works but I don’t think any one has made serious use of it. Pretty sure assembler support routines could be added to retrieve the data from an extended PLIST. ? Dave ? ? Would that rule out calling Rexx external functions written in PL/I?
It doesn't rule out calling PL/I?programs?via SVC 202 which, I think, is the way rexx external functions would need to be packaged (in sum, modules).
In any case does PL/I on VM/370 support EPLIST (i.e. has there been a mod on the 6 pack). If there are PL/I programmers out there who would like to do a mod to support the 6 word EPLIST then we would be in business :-)
Otherwise. 8 char parameters and an int return only ...?
|
Just thinking out aloud, can we avoid stack variables, and use the stack only for register save/returns? Then you could have nesting limits, like mainframe Rexx has, according to the stack you set aside. The original interpreter probably allocated storage that was needed dynamically, had no stack and needed to fit in 64K due to the Yorktown modifications to their VM.
One other assumption is that OS functions for allocating memory are slow, are we certain that is also the case on CMS? In the few reenterable assembler programs that I wrote I getmained, use the register in a DSECT mapping, and freemained it when done - if it was in CSA, otherwise let RTM clean it up. Never worried about performance, MVS has cell pool calls that were supposed to be quicker, but never needed them. We had no stack.
The problem here, I guess, is that VM/370 doesn’t have it either.
Just thought. I support the plan.
toggle quoted message
Show quoted text
On 5 Apr 2020, at 10:58, adriansutherland67 < adrian@...> wrote:
First progress (remembering I am keen to get gcclib fit for purpose asap so I can play rexx): -? GCCLIB global variables (e.g. stdin) working and being rolled out. - About to move to RESLIB only? - perror() implemented, glueing in stdio
- Will add workaround to cmscommand calltype 11
- Lots of stdio issues raised (a list always helps)
- About to glue in the famous dlmalloc() to give us best in class memory allocation (C programs should not directly use OS level memory management ... performance). E.g.?
- Move the last functions to RESLIB, see if anything critical needs implementation (e.g. registering exit functions are missing, but who trusts them anyway!)
The biggest architectural hole is the stack. About 120k allocated at startup. Bound to be too small or too big!?
So we need to use a split stack, or stacklets, see link below (obviously triggered by their problems with multithreading) for some insight in thinking. We are different but prior art etc.
Different options, and we have the advantage that stackframes don't have to be contiguous on s/370.
For performance the ideal situation is that it mostly works like now except with an extra check to see if we are out of space in the current stack segment. This check must be fast.
If we are out of space we can call a c function to make a new segment, handle linked lists etc. A problem is that will need stack space. I am considering having a buffer space (as per the link), or having a separate fixed stack for stack management.
Anyway ... the question is the fast stack space check. The obvious way is to use the reserved word 1 on the stackframe. On the basis that.
- PL/I and Fortran uses it (although I have never found anything explaining what for) so why not C!
- Assembler programmers know to avoid it!
- Is anyone going to try and link PL/I and C programs together? Of course not!
- Fastest performance.
- No other sensible options!
So this is a call for (and I appreciate negative feedback in the past) suggestions, objections, and I really hope support for this approach.
Any REXX?needs really good memory management in the underlying C library ...
Note to self ... check long jumps ...
|
Reading about PL/I in wikipedia, this always cracks me up:
Announced with IBM S/370 in 1970, it shipped first for the??operating system in August 1971, and shortly afterward for OS/360,?and the first virtual memory IBM operating systems?,?, and?. (The developers were unaware that while they were shoehorning the code into 28 kb sections, IBM Poughkeepsie was finally ready to ship virtual memory support in OS/360).
搁别苍é.
toggle quoted message
Show quoted text
Just thinking out aloud, can we avoid stack variables, and use the stack only for register save/returns? Then you could have nesting limits, like mainframe Rexx has, according to the stack you set aside.The original interpreter probably allocated storage that was needed dynamically, had no stack and needed to fit in 64K due to the Yorktown modifications to their VM.
One other assumption is that OS functions for allocating memory are slow, are we certain that is also the case on CMS? In the few reenterable assembler programs that I wrote I getmained, use the register in a DSECT mapping, and freemained it when done - if it was in CSA, otherwise let RTM clean it up. Never worried about performance, MVS has cell pool calls that were supposed to be quicker, but never needed them. We had no stack.
The problem here, I guess, is that VM/370 doesn’t have it either.
Just thought. I support the plan.
搁别苍é. On 5 Apr 2020, at 10:58, adriansutherland67 < adrian@...> wrote:
First progress (remembering I am keen to get gcclib fit for purpose asap so I can play rexx): -? GCCLIB global variables (e.g. stdin) working and being rolled out. - About to move to RESLIB only? - perror() implemented, glueing in stdio - Will add workaround to cmscommand calltype 11
- Lots of stdio issues raised (a list always helps)
- About to glue in the famous dlmalloc() to give us best in class memory allocation (C programs should not directly use OS level memory management ... performance). E.g.?
- Move the last functions to RESLIB, see if anything critical needs implementation (e.g. registering exit functions are missing, but who trusts them anyway!)
The biggest architectural hole is the stack. About 120k allocated at startup. Bound to be too small or too big!?
So we need to use a split stack, or stacklets, see link below (obviously triggered by their problems with multithreading) for some insight in thinking. We are different but prior art etc.
Different options, and we have the advantage that stackframes don't have to be contiguous on s/370.
For performance the ideal situation is that it mostly works like now except with an extra check to see if we are out of space in the current stack segment. This check must be fast.
If we are out of space we can call a c function to make a new segment, handle linked lists etc. A problem is that will need stack space. I am considering having a buffer space (as per the link), or having a separate fixed stack for stack management.
Anyway ... the question is the fast stack space check. The obvious way is to use the reserved word 1 on the stackframe. On the basis that.
- PL/I and Fortran uses it (although I have never found anything explaining what for) so why not C!?
- Assembler programmers know to avoid it!
- Is anyone going to try and link PL/I and C programs together? Of course not!
- Fastest performance.
- No other sensible options!
So this is a call for (and I appreciate negative feedback in the past) suggestions, objections, and I really hope support for this approach.?
Any REXX?needs really good memory management in the underlying C library ...
Note to self ... check long jumps ...
|
On Sun, Apr 5, 2020 at 11:35 AM, rvjansen@... wrote:
Just thinking out aloud, can we avoid stack variables,
Maybe for the REXX bytecode interpreter, but obviously C needs the stack for its local variables.
?
?
One other assumption is that OS functions for allocating memory are slow, are we certain that is also the case on CMS?
I think so - but it is a fair question. There are benchmarking programs, so I will report back what (if any) saving is generated. If CMS is in fact faster (or as fast) (and handles fragmentation well) I will not bother with the updated code, obviously. We shall see :-)
?
Just thought. I support the plan.
Thank you
?
|
BTW - does anyone know what the CP/CMS page size is? I.e. For maximum efficiency and fit what is the optimum memory request size from the OS (e.g. 4k)??
Or either - is there a lower level page request I could use? (Assuming not - never seen one documented)
A
|
The page size is 4k, just as the underlying memory is.
Joe
On Sun, Apr 5, 2020 at 7:34 AM adriansutherland67 < adrian@...> wrote: BTW - does anyone know what the CP/CMS page size is? I.e. For maximum efficiency and fit what is the optimum memory request size from the OS (e.g. 4k)??
Or either - is there a lower level page request I could use? (Assuming not - never seen one documented)
A
|
On Sun, Apr 5, 2020 at 12:42 PM, Joe Monk wrote:
The page size is 4k, just as the underlying memory is.
Thanks - and on VM/370 is there any assumptions I can make about alignment - i.e. if I requested 4k it would be our good luck if the allocated memory ...
... always ended at a N-bit boundary. E.g., if we always allocate stack segments as a multiple of 4K, then align each one so that the stack always ends at a 12-bit boundary. Then the amount of space remaining on the stack is SP & 0xfff
Any luck for us?
|
You should allocate the size you require. Efficiency is undeterminable because you are running in a simulator, not on any page boundary sensitive hardware. Also VM/370 CMS has no method to allocate a page on a page boundary, except to allocate 8K and then give back the excess allocated before?and after the page boundaries.? Bob Bolch
On Sun, Apr 5, 2020 at 8:34 AM adriansutherland67 < adrian@...> wrote: BTW - does anyone know what the CP/CMS page size is? I.e. For maximum efficiency and fit what is the optimum memory request size from the OS (e.g. 4k)??
Or either - is there a lower level page request I could use? (Assuming not - never seen one documented)
A
|
On Sun, Apr 5, 2020 at 12:57 PM, Bob Bolch wrote:
except to allocate 8K and then give back the excess allocated before?and after the page boundaries.
Cunning :-)
|
except to allocate 8K and then give back the excess allocated before?and after the page boundaries
And after that it might be "trained" to continue on the boundaries
|
搁别苍é,
I have to agree with you, that is a fit funny - the dates are a
bit off, plus other errors (???)....
The first language I used on the Mainframe was PL/I in early 1964,
followed very shortly by Assembler.
To this day, the pseudo language I usually use when designing is
a? "variation" of PL/I - and most of it would probably compile
now-a-days anyway.
/s/ Bill Turner, wb4alm
On 4/5/20 7:37 AM, rvjansen@... wrote:
toggle quoted message
Show quoted text
Reading about
PL/I in wikipedia, this always cracks me up:
Announced with IBM S/370 in 1970, it shipped first
for the??operating system in August 1971, and shortly
afterward for OS/360,?and the first virtual memory
IBM operating systems?,?, and?. (The developers were unaware that while they
were shoehorning the code into 28 kb sections, IBM
Poughkeepsie was finally ready to ship virtual memory support
in OS/360).
搁别苍é.
|
What was IBMs private system language called? That was never published was it?
|
First BSL, then PL/S, PL/AS and now PL/X. It is in circulation, you can order it (I think).
toggle quoted message
Show quoted text
On 5 Apr 2020, at 16:32, adriansutherland67 < adrian@...> wrote:
What was IBMs private system language called? That was never published was it?
|
|
|
搁别苍é, I think that the version we have is really an MFT version that’s not been properly ported to VM. It seems to rely on random storage content on start-up. ? Also some one asked about the CMS page size. One of the issues is that CMS does not have a page size. CMS thinks its running in real store. Its CP that handles the pages and provides a VM for each user. I don’t think anyone will get any significant paging load regardless of page placing. ? Dave ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of rvjansen@...
Sent: 05 April 2020 11:50
To: [email protected]
Subject: Re: [h390-vm] Dynamic / split stacks (gcclib)? It being IBM PLI/F it must have seen some serious use in the 1966-1971 era - don’t let the old Hursley geezers hear you ;-) In the 80’s-90’s I only did some voodoo programming with it - the later optimizing’ version; we had an ‘unofficial’ (but IBM sanctioned) compiler we needed for some early dynamic SQL things. It looked a lot like Rexx as I remember. I thought of using it for some of the VM extensions - anything to avoid C, also for me. 搁别苍é.
? From what I remember the free PL1 is a mess. It usually works but I don’t think any one has made serious use of it. Pretty sure assembler support routines could be added to retrieve the data from an extended PLIST. Would that rule out calling Rexx external functions written in PL/I?
It doesn't rule out calling PL/I?programs?via SVC 202 which, I think, is the way rexx external functions would need to be packaged (in sum, modules).
In any case does PL/I on VM/370 support EPLIST (i.e. has there been a mod on the 6 pack). If there are PL/I programmers out there who would like to do a mod to support the 6 word EPLIST then we would be in business :-)
Otherwise. 8 char parameters and an int return only ...?
?
|
On Sun, Apr 5, 2020 at 03:36 PM, Dave Wade wrote:
Also some one asked about the CMS page size
That was me. I'm more interested in the inner workings of dmsfre and what bucket size it uses internally and any insights on how to works so I can tune malloc. Is there a internals doco? A
|
