Let me preface this with the following:

 

I do not do assembler much anymore so I have not kept up with the new
instructions.  Also I was primarily an applications programmer not a systems
programmer.

 

Because of size limits I will separately post an example that illustrates a
program structure that I picked up from a programmer named Terry Lee at
Group1 Software.  It allows you to write very large assembler programs
without worrying about running out of registers.  An overview of the
structure is:

 

  First CSECT/Mainline

  Common Subroutines line SENTER, SEXIT, MVCL_RTN etc.

  Register equates

  Data areas DC/DS

  DSECTs

  Second CSECT

  Large data areas addressed via adcon

  General Subroutines using R( base register

  Literals 

 

The first CSECT (see SOFTOOL) uses R10, R11, and R12 as base registers.
These would address the mainline/top level driver code, data constants and
variables.  Also we would put heavily used routines here for performance.
For example instead of using MVCL we had a subroutine that used MVC and
looping.  In bygone days not all machines had the 370 machine instructions.

 

Other general subroutines were placed in a separate CSECT (see SOFTTOOL1).
These subroutines use R9 as a branch register, which does limit their size
to 4K.  For each of these subroutines an address constant is used that takes
up space out of the first CSECT because it contains the literal pool.
Usually the number of these subroutines is not a limiting factor. Branching
to these subroutines is done via the SENTER and SEXIT routines.  The 90D
SAVE area is used by the main line and the general subroutines, so that
limits how many levels (depth) of subroutine calls you may have. You can
always make it bigger but I never had to, YMMV. These subroutines, depending
upon what is passed to them in registers, are free to use register R2 to R8.
Usage of R1, R2, R13, R14, R15 follows the usual standard register
conventions.

 

In today's world you might want to dynamically acquire storage for you data
areas to avoid pipeline problems.

 

 

Reply via email to