Last question should have read "once accessed"....

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

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

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.

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

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.

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"

Its called the C calling convention (so you can google it)

I think GCCMVS uses either R13 or R14 for the stack pointer. So basically the program defines a bunch of space for its stack at the beginning (see the end of?

R13 or 14 (sorry I don't know which) points to it. When a function is called the function moves the register down enough to make space for its local variables. When the function is done it can put the stack pointer back. The return address, return value and arguments are also put / read from the stack.

Hope that makes some sense!
?

开云体育

开云体育

On 2/25/20 10:29 AM, adriansutherland67 wrote:

On Tue, Feb 25, 2020 at 02:27 PM, adriansutherland67 wrote:

ARGVARGS

No - it was ARGVARGS - (too similar names - I hate it).

Anyway bug fixed :-)

So my general policy will be to ignore this file as too hard - but maybe one day replace the parameter bits with some nice friendly C - LOL!

??? I agree that Assembler is harder than most languages, but some would say that "it separates the men from the boys".?

I guess that makes me a man since about 1982. What does knowing FORTRAN IV since 1977 do for my score?

As far a C being friendly, I guess that is in the eye of the beholder.?

"C combines the power of assembler with the portability of assembler.'' - Anonymous

BASIC and COBOL in my opinion are "friendlier".?

If you want unfriendly, try passing a character variable from PL/I (F) to Assembler.? (They cleaned it up some in the PL/I Optimizer).

OTOH, PL/I has block constructs and words for labels.? FORTRAN IV & classic BASIC having neither is the pits.? (You too can try to remember what label 502 stands for ...)

I've seen C code that makes me want an assembler program any day because the original developer was trying to be slick and fancy.

"Clever" is the bane of good coders everywhere.

Flon's Law:? There is not now, and never will be, a language in which it is the least bit difficult to write bad programs.

-ahd-

-- 
Drew Derbyshire

"Manners are a sensitive awareness of the feelings of others. If you
 have that awareness, you have good manners, no matter what fork you
 use."                                          -- Emily Post

On Tue, Feb 25, 2020 at 05:02 PM, rvjansen@... wrote:

(Would just initializing everything solve that scenario?).

Yes - and in C I believe the standard is that the compiler initializes variables for you - this case it was some assembler code (which I consider a dark art!)

As you know C uses a stack for local variables - so reentrancy is not an issue. But for global variables (static, extern), it just adds then to the code flat - which is why you had to and we have to code in such a way as to avoid globals - in this case we will have to use getmain, and use a stack to track which set of "global variables" should be exposed.

When we enter main() we push a new struct, when we leave we pop one off (I am sure error conditions causing a program exit where we have forgotten to "pop" will cause us lots of insane bugs {shrug}).

Modern linkers are different - they take care of all this without programmers noticing. If two programs link to a shared library dynamically all the globals are initialised sanly and transparently, and remember with C++ this is not trivial!

A

开云体育

On 25 Feb 2020, at 17:56, adriansutherland67 <adrian@...> wrote:

On Tue, Feb 25, 2020 at 04:39 PM, rvjansen@... wrote:

compiler that generates reentrant code

Its the linker that is the issue.

Anyway "all" we have to do is pull out all the globals that BREXX use and put them in a struct. Each call (recursive/reentrant) to BREXX instanciates a struct object, organised as a stack - job's done :-) ha!

It will never be multithreaded - but that is irrelevant for CMS.

This defect was just one of those weird ones ...

I will be interested if you find any more funny IO scenarios - it would be good to just get stability / confidence.

In fact, I am going to add a reentrant checker to block these calls so as to avoid confusion until we get it working properly.

Adrian

开云体育

I will need to read the old CMS books, but for MVS you’ll need the list-versions of the macro’s (MF=L) and map a getmained chunk of memory. Mike’s original Rex interpreter code was reentrant assembler and had to deal with paging drums etc.

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.

开云体育

My guess would be local as I don't see anything in the code to indicate that would be re-entrant or designed to be loaded resident, but I will defer to the current maintainers.? A shared stack is usually created via a "GETMAIN" type call with uses memory outside of program storage with its address stored in a Control Block type construct.

Gary

开云体育

On Tue, Feb 25, 2020 at 02:27 PM, adriansutherland67 wrote:

ARGVARGS

No - it was ARGVARGS - (too similar names - I hate it).

Anyway bug fixed :-)

So my general policy will be to ignore this file as too hard - but maybe one day replace the parameter bits with some nice friendly C - LOL!

??? I agree that Assembler is harder than most languages, but some would say that "it separates the men from the boys".? As far a C being friendly, I guess that is in the eye of the beholder.? BASIC and COBOL in my opinion are "friendlier".? I've seen C code that makes me want an assembler program any day because the original developer was trying to be slick and fancy.

My SOP is to use the language that best fits the purpose.? If you think assembler is hard, try writing machine code patches.? Loads of fun...

Gary

On Tue, Feb 25, 2020 at 12:09 PM, gdblodgett wrote:

The DS in the MAINSTK statement means Define Storage.? The 32000F states that variable 32000 "F"s in size.? With "F" meaning a full word (4 bytes) aligned on a full word boundary.? So it's 32000 x 4 = 128000 bytes long, aligned on a full word boundary.?

So does this mean that the stack is local to each instance of the program? I.e. if 2 programs link with GCCLIB will they have the same stack, or not??

Presumably if the stack was defined as part of the GCCLIB loaded resident then they would indeed share the same stack - disastrously!

Thanks for any hints!

On Tue, Feb 25, 2020 at 02:27 PM, adriansutherland67 wrote:

ARGVARGS

No - it was ARGVARGS - (too similar names - I hate it).

Anyway bug fixed :-)

So my general policy will be to ignore this file as too hard - but maybe one day replace the parameter bits with some nice friendly C - LOL!