Assembler Clarification

[Ron Hudson]

Hey Wizards of Assembly Language..

It looks to me like one of the first things a program does in setting up
it's own environment
is tell the CPU where to put the registers? Are do the registers actually
reside in memory?
Does each program get it's own set of registers? Gee that would make context
changes
really easy..

(Not starting assembly language just yet but interested...)

Thanks.

[peter.thingsted]

The first thing a program needs to do is to save the contents of the general registers (16 of them ) in memory.

The general registers are to be thought of as separate electronic pieces of storage - outside the main storage.

You need to save the contents of these registers when your program starts running, and restore them after your program has finished doing whatever it is programmed to do.

One register (14) is especially important to preserve, because it contains the return address of the calling program, i.e. the program that was running just before your assembler program. So the very last instruction in your program should be a BR 14, i.e branch to the machine instruction stored in the memory location that register 14 poinded to when YOUR program took over.

You can play with one register for good effects just before your BR 14 instucton. You can put a value in register 15, e.g. a big fat zero by coding SR 15,15. This signals that all ended well. It is customary (but not required or in any way enforced) that you can put various powers of 2 into reg 15 to signal any number of abnormal situations thet your program detected.

The latter here is part of what we call the linkage conventions. Note that they are conventions not enforced by any part of MVS - but you best know these conventions otherwise your program wil not cooperate well with all the other programs that taken together constitute the MVS sustem.

Rgs,

Peter
mvsaudit.org

Post by Ron Hudson
Hey Wizards of Assembly Language..
It looks to me like one of the first things a program does in setting up
it's own environment
is tell the CPU where to put the registers? Are do the registers actually
reside in memory?
Does each program get it's own set of registers? Gee that would make context
changes
really easy..
(Not starting assembly language just yet but interested...)
Thanks.

[Ron Hudson]

The return address is stored in a register? No recursion... right?

Is there a stack?

Post by peter.thingsted
The first thing a program needs to do is to save the contents of the
general registers (16 of them ) in memory.
The general registers are to be thought of as separate electronic pieces of
storage - outside the main storage.
You need to save the contents of these registers when your program starts
running, and restore them after your program has finished doing whatever it
is programmed to do.
One register (14) is especially important to preserve, because it contains
the return address of the calling program, i.e. the program that was running
just before your assembler program. So the very last instruction in your
program should be a BR 14, i.e branch to the machine instruction stored in
the memory location that register 14 poinded to when YOUR program took over.
You can play with one register for good effects just before your BR 14
instucton. You can put a value in register 15, e.g. a big fat zero by coding
SR 15,15. This signals that all ended well. It is customary (but not
required or in any way enforced) that you can put various powers of 2 into
reg 15 to signal any number of abnormal situations thet your program
detected.
The latter here is part of what we call the linkage conventions. Note that
they are conventions not enforced by any part of MVS - but you best know
these conventions otherwise your program wil not cooperate well with all the
other programs that taken together constitute the MVS sustem.
Rgs,
Peter
mvsaudit.org

Post by Ron Hudson
Hey Wizards of Assembly Language..
It looks to me like one of the first things a program does in setting up
it's own environment
is tell the CPU where to put the registers? Are do the registers actually
reside in memory?
Does each program get it's own set of registers? Gee that would make

context

Post by Ron Hudson
changes
really easy..
(Not starting assembly language just yet but interested...)
Thanks.

[Tuomo Stauffer]

Hi - yes, recursion, multi-tasking, pipelining, etc, others are still
catching up! No stack, thanks! So, no stack overflows, no security problems
in that sense, no code injection, no push / pop nightmare, etc.

Now : try IBM System/370 Systems Principles of Operation - it explains these
very nicely (already 1970!) -

http://bitsavers.org/pdf/ibm/370/princOps/GA22-7000-0_370_Principles_Of_Operation_Jun70.pdf

have a nice day - tuomo

ps. there are later versions of "Principles of Operation" but this isn't too
bad.

Post by Ron Hudson
The return address is stored in a register? No recursion... right?
Is there a stack?

Post by peter.thingsted
The first thing a program needs to do is to save the contents of the
general registers (16 of them ) in memory.
The general registers are to be thought of as separate electronic pieces
of storage - outside the main storage.
You need to save the contents of these registers when your program starts
running, and restore them after your program has finished doing whatever it
is programmed to do.
One register (14) is especially important to preserve, because it contains
the return address of the calling program, i.e. the program that was running
just before your assembler program. So the very last instruction in your
program should be a BR 14, i.e branch to the machine instruction stored in
the memory location that register 14 poinded to when YOUR program took over.
You can play with one register for good effects just before your BR 14
instucton. You can put a value in register 15, e.g. a big fat zero by coding
SR 15,15. This signals that all ended well. It is customary (but not
required or in any way enforced) that you can put various powers of 2 into
reg 15 to signal any number of abnormal situations thet your program
detected.
The latter here is part of what we call the linkage conventions. Note that
they are conventions not enforced by any part of MVS - but you best know
these conventions otherwise your program wil not cooperate well with all the
other programs that taken together constitute the MVS sustem.
Rgs,
Peter
mvsaudit.org

Post by Ron Hudson
Hey Wizards of Assembly Language..
It looks to me like one of the first things a program does in setting up
it's own environment
is tell the CPU where to put the registers? Are do the registers

actually

Post by Ron Hudson
reside in memory?
Does each program get it's own set of registers? Gee that would make

context

Post by Ron Hudson
changes
really easy..
(Not starting assembly language just yet but interested...)
Thanks.

[Mike Schwab]

Where you store the registers is called a save area. These are
forward and backward linked like a stack. For Open System Services, a
hardware stack was added in OS/390.

Upon Entry,
R0 can be used as a binary number, but is evaluated as 0 as an address value.
R1 points to a list of addresses to the parameters, the high order bit
is set to 1 for the last 24/31 bit address.
R2 is used by some instructions and an alternative cannot be coded..
R2-12 can be used as base registers.
R13 points to the previous save area, which you use to store the registers.
R14 points to the return address, where you branch when you are done.
R15 points to the entry address, the first instruction in your program.
R2 is used by some instructions.
R2-12 can be used as base registers.
R15 is used as a base address until you get your own going.

Post by Ron Hudson
The return address is stored in a register? No recursion... right?
Is there a stack?

Post by peter.thingsted
The first thing a program needs to do is to save the contents of the general registers (16 of them ) in memory.
The general registers are to be thought of as separate electronic pieces of storage - outside the main storage.
You need to save the contents of these registers when your program starts running, and restore them after your program has finished doing whatever it is programmed to do.
One register (14) is especially important to preserve, because it contains the return address of the calling program, i.e. the program that was running just before your assembler program. So the very last instruction in your program should be a BR 14, i.e branch to the machine instruction stored in the memory location that register 14 poinded to when YOUR program took over.
You can play with one register for good effects just before your BR 14 instucton. You can put a value in register 15, e.g. a big fat zero by coding SR 15,15. This signals that all ended well. It is customary (but not required or in any way enforced) that you can put various powers of 2 into reg 15 to signal any number of abnormal situations thet your program detected.
The latter here is part of what we call the linkage conventions. Note that they are conventions not enforced by any part of MVS - but you best know these conventions otherwise your program wil not cooperate well with all the other programs that taken together constitute the MVS sustem.
Rgs,
Peter
mvsaudit.org

Post by Ron Hudson
Hey Wizards of Assembly Language..
It looks to me like one of the first things a program does in setting up
it's own environment
is tell the CPU where to put the registers? Are do the registers actually
reside in memory?
Does each program get it's own set of registers? Gee that would make context
changes
really easy..
(Not starting assembly language just yet but interested...)
Thanks.

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

[Rick Fochtman]

-------------------------------<snip>-----------------------------------
Where you store the registers is called a save area. These are forward
and backward linked like a stack. For Open System Services, a hardware
stack was added in OS/390.

Upon Entry,

Post by Mike Schwab
R0 can be used as a binary number, but is evaluated as 0 as an address value.
R1 points to a list of addresses to the parameters, the high order bit
is set to 1 for the last 24/31 bit address.
R2 is used by some instructions and an alternative cannot be coded..
R2-12 can be used as base registers.
R13 points to the previous save area, which you use to store the registers.
R14 points to the return address, where you branch when you are done.
R15 points to the entry address, the first instruction in your program.
R2 is used by some instructions.
R2-12 can be used as base registers.
R15 is used as a base address until you get your own going.

------------------------------<unsnip>--------------------------------
If you're an "Artful Dodger" like me, you can use R13, the save area
pointer, as a base register as well. Note the following code snippets:

MYNAME CSECT
B 12(,15)
BRANCH AROUND ...
DC AL1(7),CL7,'MYNAME' CSECT ID FOR DUMP
PROCESSOR
STM 14,12,12(13) SAVE
ENTRY REGISTERS
BAL 2,92(,15) SCOOT
AROUND NEW SAVE AREA
USING *,13
DECLARE THE BASE REGISTER
DS 18F
NEW SAVE AREA
XC 0(72,2),0(2) CLEAR
NEW SAVE AREA
ST 2,8(,13)
STORE DOWNWARD POINTER
ST 13,4(,2)
STORE UPWARD POINTER
LR 13,2
LOAD SA POINTER/BASE REG
.....
..... (whatever your program or
subroutine needs to do)
.....
* EXIT CODE
L 13,4(,13)
LOAD BACK S.A. POINTER
L 14,12(,13)
LOAD RETURN ADDRESS
LM 2,12,28(13)
RESTORE SIGNIFICANT REGS
LA 15,0
SET RETURN CODE ZERO
BR 14
RETURN TO CALLER(USUALLY MVS INITIATOR)

Note that this code is NOT reentrant. It's offered here strictly for
illustrative purposes. Reuse as you see fit.

Note also that all registers except the Save Area pointer are saved;
preserving 14,15,0 and 1 are highly useful in debugging, for tracing
back parameter information and call paths.

This is one example of entry/exit linkage for an assembler program or a
subroutine called by another assembler program or a high-level language
routine. It works fine for FORTRAN, COBOL and Assembler programs, but
PL/1 linkage is far more complex due to the various data formats used
within and between PL/1 programs. I don't propose to got into that in
detail.

Rick

[Roger Bowler]

Post by Ron Hudson
The return address is stored in a register? No recursion... right?
Is there a stack?

There's a famous quote in this article by the late Jim Keohane:
http://searchdatacenter.techtarget.com/tip/0,289483,sid%2010_gci528005,00.html
"Stack? S/360 don't need no stinkin' stack!"

Regrettably, as mentioned elsewhere, IBM have chosen to remove the
referenced Journal of Research and Development article from their
website http://www.research.ibm.com/journal/rd/441/amdahl.pdf

--
Regards,
Roger Bowler
http://perso.wanadoo.fr/rbowler
Hercules "I can't believe it's not a mainframe!"

[e.sorichetti]

Post by Roger Bowler
...
Regrettably, as mentioned elsewhere, IBM have chosen to remove the
referenced Journal of Research and Development article from their
website http://www.research.ibm.com/journal/rd/441/amdahl.pdf
...

Nahh ! :-)
they are available but they make You pay 30 F***ING $ for each one !
short history ...
free
3$ each
39$ each direct from IBM
30$ each from IEEE

regards
e.s

[au1john]

A company I used to work for had some IBMers from the US come on site for a
project (I'm in Australia). One of those IBMers had a clean out of stuff
that he obviously had shipped here. I picked up about 12-15 shelf inches of
IBM Systems Journal from the 1960s. I have a feeling that I have some
relating to S/360 design including Dr Gene's articles.
Now I just have to find them and see what I actually have. I know I
collected them and I know that I did not throw them out; my spouse however
is another story!
Off to the storage unit when convenient.

I'm wondering if this is now a bit OT for these groups?

Group owners/surrogates?

[n9gtm]

Post by au1john
I'm wondering if this is now a bit OT for these groups?
Group owners/surrogates?

John, it's a bit OT but not _that_ much. A fair amount of what
we deal with regards retrocomputing and such discussions
inevitably surface. You're also welcome in hercules-s370asm,
hercules-offtopic, and H390-MVS (I also happen to moderate - to
various degrees - in those forums). For a free-ranging discussion,
try the new hercules-offtopic, for specific areas like assembler
s370asm, etc.

I'd say if it gets to be a long discussion, consider moving it
but otherwise don't worry about it.

BTW, for the OP, the s370asm group has a S/370 assembler tutorial;
see the home page to find the latest version.

Jim, moderator

[yvette hirth]

Post by Ron Hudson
The return address is stored in a register? No recursion... right?

for MVS, MVS/XA, MVS/ESA and z/OS, the addr to return to is indeed
stored in GPR 14 when the program is given control.

if i understand what you mean by recursion, then no. of course, if you
fail to store the return addr when you get control, yes, you can easily
mess up the return addr.

Post by Ron Hudson
Is there a stack?

for z/OS, there is no "heap"-type stack, but yes, there is a "mainframe"
form of a stack, called the save area trace. it is a noncontiguous
doubly-linked (i.e., backwards and forwards) stack.

there is no pc-style "heap" wrt program linkage and register saving, but
iirc there are heaps used in some areas of z/OS (advanced stuff; PC / PR
instructions, etc).

for more information, you could read the Principles Of Operation (POPs)
for z/OS and Assembler Language Reference / Macros. POPs will explain
the instructions; the ASM manuals should show you program linkage
methodology (program linkage methodology remains basically unchanged
since the 1960's). it's not "light reading" (i used to read POPs when i
had insomnia...)

try here:

http://www-03.ibm.com/systems/z/os/zos/bkserv/r11pdf/

also please note that while DOS/VS(E), (z/)VM, and z/OS all use pretty
much the same instruction set, they all have different linkage
methodologies.

hth
yvette hirth

[Rick Fochtman]

--------------------------------------<snip>----------------------------
for z/OS, there is no "heap"-type stack, but yes, there is a "mainframe"
form of a stack, called the save area trace. it is a noncontiguous
doubly-linked (i.e., backwards and forwards) stack.
---------------------------------<unsnip>----------------------------------
Actually, it's more properly named a doubly-linked list. :-) "SAVE AREA
TRACE" is what dump processing calls it when it's printed out.

------------------------------------<snip>------------------------------------
there is no pc-style "heap" with program linkage and register saving,
but iirc there are heaps used in some areas of z/OS (advanced stuff; PC
/ PR instructions, etc).
----------------------------------<unsnip>----------------------------------
PC/PR linkages have been established since MVS/XA and use hardware
stacks, but the old "traditional" S/360 types of linkages still work
just fine. z/OS uses a variety of linkage conventions, including BALR,
BAKR, BASSM and PC/PR, depending on the requirements. PC/PR are
especially useful since they allow a Address Space Switch event. Much
faster than SVC events for some supervisor services, like
ENQ/DEQ/RESERVE and STORAGE (replacement for GETMAIN/FREEMAIN). SVC
events are really very slow, because of the hardware and software
overhead in processing an interrupt.

---------------------------------------<snip>----------------------------------
for more information, you could read the Principles Of Operation (POPs)
for z/OS and Assembler Language Reference / Macros. POPs will explain
the instructions; the ASM manuals should show you program linkage
methodology (program linkage methodology remains basically unchanged
since the 1960's). it's not "light reading" (i used to read POPs when i
had insomnia...)
-------------------------------------<unsnip>-------------------------------
I found that Program Logic manuals served equally well for insomnia. :-)
"Supervisor Services" also has a fair description of program linkage
conventions.

----------------------------------------<snip>----------------------------------
also please note that while DOS/VS(E), (z/)VM, and z/OS all use pretty
much the same instruction set, they all have different linkage
methodologies.
--------------------------------------<unsnip>-----------------------------------
Most, if not all, the various linkage conventions are available on all
those systems. Most of the "dependance" is based on the available
instruction set.

Rick
<mailto:yvette-RPrnXxQTqyxWk0Htik3J/***@public.gmane.org?subject=Re:%20%5Bturnkey-mvs%5D%20Re:%20Assembler%20Clarification>
<mailto:turnkey-mvs-***@public.gmane.org?subject=Re:%20%5Bturnkey-mvs%5D%20Re:%20Assembler%20Clarification>

[Mike Stramba]

Hi Ron,

I'm no wizard, but I like to dabble with assembler.

Post by Ron Hudson
It looks to me like one of the first things a program does in setting up
it's own environment is tell the CPU where to put the registers? Are do the registers actually
reside in memory? Does each program get it's own set of registers? Gee that would make >context changes really easy..

You're only saving a *copy* of the current contents of the registers,
and this is only necessary, in the case where your program has been
called by another program, i.e. the O.S., when your program starts
running.

So when you save them with some variant of the ST(ore), STM( store
multiple) command, the saved copies *are* in memory. The registers
themselves are part of the CPU hardware, not the memory hardware
(unlike many microcontrollers, like the PIC, where the "registers" are
really just memory addresses).

By changing the ARCHMODE config variable, Hercules can emulate three
different architectures :

1) S/370

All of the "old" O.S'.s we're running run S/370 mode (** VM380
runs in ESA/390 mode ... )

#2009-09-11 22:30:00
ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf
http://bitsavers.org/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf

#2009-09-11 22:29:00
ibm/370/princOps/GA22-7000-0_370_Principles_Of_Operation_Jun70.pdf
http://bitsavers.org/pdf/ibm/370/princOps/GA22-7000-0_370_Principles_Of_Operation_Jun70.pdf

Although ESA/390, Z/arch(ESAME) won't be applicable when running
Turnkey MVS (as it runs in ARCHMODE S/370). You *can* run ARCHMODE
ESA/390, Z/arch (ESAME) on the "bare metal" though (no O.S. just
using raw assembler).

I started a wiki on "bare metal" programming :
http://hercules-bare-metal.wikispaces.com/

ESA / 390
http://publibz.boulder.ibm.com/epubs/pdf/dz9ar008.pdf

Z/arch
http://publibz.boulder.ibm.com/epubs/pdf/dz9zr007.pdf

Zarch Summary / Reference Card
http://publibz.boulder.ibm.com/epubs/pdf/dz9zs005.pdf

[yvette hirth]

Post by Mike Stramba
Zarch Summary / Reference Card
http://publibz.boulder.ibm.com/epubs/pdf/dz9zs005.pdf

*ninety two* pages? sheesh, i remember when it was 8!

yvette hirth

[Mike Stramba]

And I remember when I had a "big /powerful" p.c. (386 with 16 meg memory)
.... heck our college's 4341 only had 16 meg ! :)

Post by yvette hirth
*ninety two* pages? sheesh, i remember when it was 8!
yvette hirth