Re: Eliminating Base Registers (was: Inlining routines)

[Seymour J Metz]

I much prefer having eyecatchers show up in save area tracebacks, even if that 
"wastes" space.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of Martin Trübner [mar...@pi-sysprog.de]
Sent: Saturday, April 2, 2022 12:55 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Eliminating Base Registers (was: Inlining routines)

Charles (et al),


I like the entry being at the CSECT and the base pointing to the entry
of the CSECT (and I am lazy) so I borrowed  a neat technique from Ed Jaffe


I marked it with "<--- this is new " in your sample


It costs only 4bytes and helps me.


TEST CSECT
MAIN1LOCTR
  J MYENTRY <- this is new
M1   DC'Eyecatcher at front of CSECT'
MAIN2LOCTR
  DSHalignment
MYENTRY  EQU   *
  ENTRY MYENTRY<- this is superfloush now
  SAVE  ...
  LARL  R12,TEST   no more BALRs!
  USING TEST,R12
  code ...

MAIN1LOCTR
* put any macros that need a base in little subroutines here
  LTORG
  Small constants and, if CSECT not relocatable, work areas

MAIN2LOCTR
  Any large buffers or tables
  END


Martin

Re: Eliminating Base Registers (was: Inlining routines)

[Bernd Oppolzer]

Thanks.

When I started programming in ASSEMBLER (and teaching) in the mid 1980s,
I didn't think much about base registers in the beginning. I also used 
one base register
when starting the mainline, and I used BAL R5,SUBR and BR R5 to manage 
my internal

subroutines. This worked OK for me.

This changed dramatically, when I was in charge starting from 1988 in a 
big insurance company
with a large ASSEMBLER code base. The programs there had typical sizes 
of 20.000 lines and
more, they used SP macros (structured programming) and many 
site-spezific special purpose
macros and they had macros to organize the internal subroutines, where 
the internal subs
created their own base registers. The module sizes were large, most of 
the time more than

16 times 4k.

The typical module layout is as follows:

Mainline CSECT ... covered by two base regs (for example 13 and 12)
LTORG
Mainline Static Data
First Subroutine ... covered by two base regs (for example 10 and 11)
LTORG
First Subroutine local Static Data
Second Subroutine ... covered by two base regs (again 10 and 11)
LTORG
Second Subroutine local Static Data
.. and so on

You may notice, that 4 registers are sufficient to create very large 
programs.
Register 13 is used as base register for the mainline AND for the local 
save area.


There are variants of this scheme:

- maybe you don't need two base regs on the subroutines

- maybe your program must be RENT, then the startup macro builts a DSECT
where all the automatic data is collected, and the startup macro 
allocates dynamic
space for it. In this case, of course, reg 13 cannot be used as base 
register for the
static save area, because it must point to the beginning of the 
automatic area

in the RENT case.

In 2013, I was in charge of maintaining the macro library of this 
insurance company,

and I changed the macros to support code sections without base registers.
The module in this case looks much the same as above, but the base 
registers

now don't point to the beginning of the CSECT and subroutines, but rather
to the end. The code sections are not covered with base registers, and the
B instructions are changed to J instructions using the well-known IBM 
mechanisms

(this is MVS, BTW).

In the "lucky" case, a change of parameters in the startup macro and a 
simple recompile
is sufficient to convert a program to baseless. But in reality, this is 
rare,

because most of the time there are some inline definitions in some macros
which need additional work.

Since mid 2021, I am again in charge for the macro library :-)
after a 6 year intermission. The company lost a lot of old folks with 
good ASSEMBLER

knowledge by retirement. My work here will hopefully last until 2026,
when the company plans to finally migrate the applications to other 
platforms.


HTH, kind regards

Bernd




Am 02.04.2022 um 18:25 schrieb Charles Mills:

A couple of things.

One, yes, my assertion that it is easy was based on my own experience primarily
with modest-sized programs that I had written myself -- in some cases years 
earlier.
If you are talking about 10,000 lines of spaghetti enhanced over the years by 
lots of folks,
with embedded local macros and various cleverness, then it could be a large and 
fraught project.

...

b. I think all of my programs use a code base register. One code base register. 
One.
I am advocating for (i) getting rid of "4K anxiety" and (ii) freeing up a 
register or two
in those old programs with two or three code base registers.

Re: Eliminating Base Registers (was: Inlining routines)

[Charles Mills]

No argument from me. Diff'rent strokes for diff'rent folks. I don't "mind" 
having the entry point being in the middle of the CSECT, but if you do ...

If someone is using an entry point macro like EDCPRLG you would have to put 
*it* at the front of the CSECT and put J MYCODE right after it. 

A lot of my modules are collections of little MVS services for use by REXX or 
C++ code, so I have lots of modules with multiple entry points. Some of them 
are inevitably in the middle of the CSECT, whether I like it or not.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Martin Trübner
Sent: Saturday, April 2, 2022 9:56 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Eliminating Base Registers (was: Inlining routines)

Charles (et al),


I like the entry being at the CSECT and the base pointing to the entry 
of the CSECT (and I am lazy) so I borrowed  a neat technique from Ed Jaffe


I marked it with "<--- this is new " in your sample


It costs only 4bytes and helps me.


TEST CSECT
MAIN1LOCTR
  J MYENTRY <- this is new
M1   DC'Eyecatcher at front of CSECT'
MAIN2LOCTR
  DSHalignment
MYENTRY  EQU   *
  ENTRY MYENTRY<- this is superfloush now
  SAVE  ...
  LARL  R12,TEST   no more BALRs!
  USING TEST,R12
  code ...

MAIN1LOCTR
* put any macros that need a base in little subroutines here
  LTORG
  Small constants and, if CSECT not relocatable, work areas

MAIN2LOCTR
  Any large buffers or tables
  END


Martin

Re: Eliminating Base Registers (was: Inlining routines)

[Martin Trübner]

Charles (et al),


I like the entry being at the CSECT and the base pointing to the entry 
of the CSECT (and I am lazy) so I borrowed  a neat technique from Ed Jaffe



I marked it with "<--- this is new " in your sample


It costs only 4bytes and helps me.


TEST CSECT
MAIN1LOCTR
 J MYENTRY <- this is new
M1   DC'Eyecatcher at front of CSECT'
MAIN2LOCTR
 DSHalignment
MYENTRY  EQU   *
 ENTRY MYENTRY<- this is superfloush now
 SAVE  ...
 LARL  R12,TEST   no more BALRs!
 USING TEST,R12
 code ...

MAIN1LOCTR
* put any macros that need a base in little subroutines here
 LTORG
 Small constants and, if CSECT not relocatable, work areas

MAIN2LOCTR
 Any large buffers or tables
 END


Martin

Re: Eliminating Base Registers (was: Inlining routines)

[Charles Mills]

Should be

 LARL  R12,TEST   no more BALRs!
 USING TEST,R12

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Charles Mills
Sent: Saturday, April 2, 2022 9:25 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Eliminating Base Registers (was: Inlining routines)

A couple of things.

One, yes, my assertion that it is easy was based on my own experience primarily 
with modest-sized programs that I had written myself -- in some cases years 
earlier. If you are talking about 10,000 lines of spaghetti enhanced over the 
years by lots of folks, with embedded local macros and various cleverness, then 
it could be a large and fraught project.

Two, I am not advocating for "baseless" programming -- eliminating base 
registers like they were forbidden GOTOs in some COBOL program.

a. Relative jumps are goodness in any event. They are thought to be generally 
faster than based branches. So even if you did nothing else, replacing 90% of 
your branches with jumps could be a good thing.

b. I think all of my programs use a code base register. One code base register. 
One. I am advocating for (i) getting rid of "4K anxiety" and (ii) freeing up a 
register or two in those old programs with two or three code base registers. 
Here's the structure (and apologies for starting from @Peter's example) -- 
untested, of course

TEST CSECT
MAIN1LOCTR
M1   DC'Eyecatcher at front of CSECT'

MAIN2LOCTR
 DSHalignment
MYENTRY  EQU   *
 ENTRY MYENTRY
 SAVE  ...
 LARL  R12,MAIN1   no more BALRs!
 USING MAIN1,R12
 code ...

MAIN1LOCTR
* put any macros that need a base in little subroutines here
 LTORG
 Small constants and, if CSECT not relocatable, work areas

MAIN2LOCTR
 Any large buffers or tables
 END

So long as MAIN1 is less than 4K the whole thing will work with just the one 
code base register, no matter how long MAIN2 is. The organization in storage is

R12 points here --> MAIN1
  Eyecatcher
  LTORG
  Macro subroutines
  Small constants
MAIN2
  Main code
4K addressability ends somewhere above or below here
  Large buffers and tables

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Bernd Oppolzer
Sent: Friday, April 1, 2022 2:51 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Eliminating Base Registers (was: Inlining routines)

See some answers below.

In general the elimination of base registers for the code section
with existing large programs is a major task and needs careful testing.
I did this sometimes, and I had many issues and headaches, until the
programs worked (again). More hints below ...

Kind regards

Bernd


Am 01.04.2022 um 20:41 schrieb Dave Clark:
> "IBM Mainframe Assembler List"  wrote on
> 04/01/2022 02:14:38 PM:
>> Where I disagree is on the base register issue. Base registers and
>> code addressability issues should have gone away. It is pretty
>> trivial to replace old branches with their newer relative
>> counterparts. Should be faster code, too, FWIW.
>
>  OK, I'll bite.  This discussion has probably been done before but
> I wasn't around for that.  Forgive my newbie questions -- even though I
> have been programming in assembler on and off since 1978.  That said...
>
>  I understand relative branching on a basic level.  But I haven't
> really looked into them and haven't used them at all to this point.  So...
>
> 1. Is it as simple as just using a different mnemonic for the branch?

In general, yes, but, see above, there are different problems,
with IBM or site-specific macros which generate inline definitions etc.
and literals etc. ... and which assume that there is a base register which
covers the code section. You can change them, or you can establish a
temporary base (maybe register 1,14, 15) around the macro call.


> 2. Does the target label still have to be within 4K for the relative
> branch?

No, even the simple relative branches can reach 64 k in both directions
from the current PSW


> 3. ...or is there an extended relative branch that uses the extended
> displacement feature?

there are extended branches, but when converting existing programs,
you normally don't need them


> 4. What about the target for the EXecute instruction?  Is there a relative
> version of this?

no need for this during normal conversion, because you need a base register
for the data part, anyway, and the target of the EX is in the data part


> 5. Even if code base register(s) is(are) eliminated, you still need a data
> base register -- yes?

yes, sure. If you read my former post about local procedures, which ha

Re: Eliminating Base Registers (was: Inlining routines)

[Charles Mills]

A couple of things.

One, yes, my assertion that it is easy was based on my own experience primarily 
with modest-sized programs that I had written myself -- in some cases years 
earlier. If you are talking about 10,000 lines of spaghetti enhanced over the 
years by lots of folks, with embedded local macros and various cleverness, then 
it could be a large and fraught project.

Two, I am not advocating for "baseless" programming -- eliminating base 
registers like they were forbidden GOTOs in some COBOL program.

a. Relative jumps are goodness in any event. They are thought to be generally 
faster than based branches. So even if you did nothing else, replacing 90% of 
your branches with jumps could be a good thing.

b. I think all of my programs use a code base register. One code base register. 
One. I am advocating for (i) getting rid of "4K anxiety" and (ii) freeing up a 
register or two in those old programs with two or three code base registers. 
Here's the structure (and apologies for starting from @Peter's example) -- 
untested, of course

TEST CSECT
MAIN1LOCTR
M1   DC'Eyecatcher at front of CSECT'

MAIN2LOCTR
 DSHalignment
MYENTRY  EQU   *
 ENTRY MYENTRY
 SAVE  ...
 LARL  R12,MAIN1   no more BALRs!
 USING MAIN1,R12
 code ...

MAIN1LOCTR
* put any macros that need a base in little subroutines here
 LTORG
 Small constants and, if CSECT not relocatable, work areas

MAIN2LOCTR
 Any large buffers or tables
 END

So long as MAIN1 is less than 4K the whole thing will work with just the one 
code base register, no matter how long MAIN2 is. The organization in storage is

R12 points here --> MAIN1
  Eyecatcher
  LTORG
  Macro subroutines
  Small constants
MAIN2
  Main code
4K addressability ends somewhere above or below here
  Large buffers and tables

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Bernd Oppolzer
Sent: Friday, April 1, 2022 2:51 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Eliminating Base Registers (was: Inlining routines)

See some answers below.

In general the elimination of base registers for the code section
with existing large programs is a major task and needs careful testing.
I did this sometimes, and I had many issues and headaches, until the
programs worked (again). More hints below ...

Kind regards

Bernd


Am 01.04.2022 um 20:41 schrieb Dave Clark:
> "IBM Mainframe Assembler List"  wrote on
> 04/01/2022 02:14:38 PM:
>> Where I disagree is on the base register issue. Base registers and
>> code addressability issues should have gone away. It is pretty
>> trivial to replace old branches with their newer relative
>> counterparts. Should be faster code, too, FWIW.
>
>  OK, I'll bite.  This discussion has probably been done before but
> I wasn't around for that.  Forgive my newbie questions -- even though I
> have been programming in assembler on and off since 1978.  That said...
>
>  I understand relative branching on a basic level.  But I haven't
> really looked into them and haven't used them at all to this point.  So...
>
> 1. Is it as simple as just using a different mnemonic for the branch?

In general, yes, but, see above, there are different problems,
with IBM or site-specific macros which generate inline definitions etc.
and literals etc. ... and which assume that there is a base register which
covers the code section. You can change them, or you can establish a
temporary base (maybe register 1,14, 15) around the macro call.


> 2. Does the target label still have to be within 4K for the relative
> branch?

No, even the simple relative branches can reach 64 k in both directions
from the current PSW


> 3. ...or is there an extended relative branch that uses the extended
> displacement feature?

there are extended branches, but when converting existing programs,
you normally don't need them


> 4. What about the target for the EXecute instruction?  Is there a relative
> version of this?

no need for this during normal conversion, because you need a base register
for the data part, anyway, and the target of the EX is in the data part


> 5. Even if code base register(s) is(are) eliminated, you still need a data
> base register -- yes?

yes, sure. If you read my former post about local procedures, which had
for example two base registers in the past, you may now reduce the
two base registers to one, and the one covers the "local" data area
of the local procedure, which is the data area which lies behind the
code section of the local procedure. The code section doesn't need
a base register any more. With the older technique, both code and
data ar

Re: Inlining routines

[Peter Relson]

Three approaches that would normally be used are macro, a copy file, and LOCTR.
Many would avoid a copy file if the source has to be placed in a separate part 
because it can be harder to maintain.
But if multiple modules want to be able to include this same code, macro and 
copy file are the way to go.

Here's a simple example with LOCTR
TEST CSECT
MAIN1LOCTR
M1   DSF

SUBR LOCTR

MAIN2LOCTR
M2A  DSF

SUBR LOCTR
S1   DSF

MAIN2LOCTR
M2B  DSF
 END

The order of instructions in the OBJ will be M1, S1, M2A M2B

Peter Relson
z/OS Core Technology Design

Re: Eliminating Base Registers (was: Inlining routines)

[Bernd Oppolzer]

I would like to add:

I saw old large programs with mixed code and data areas
where some people without much knowlegde simply used 3, 4 or 5 base 
registers
to covers the whole program, no matter if it consisted of code sections, 
data areas

or subroutines. Of course, they ran out of registers.

When I had to do maintenance on them, I simply inserted some of my 
procedure macros
to make the "subroutines" to units which have individual base registers 
(all the same),
this way reducing the number of overall base registers from 5 to 2. This 
was done

WITHOUT converting the program to baseless.

The change was a pure technical change, and turned the programs immediately
in a maintainable state. This was on VSE, BTW.

Kind regards

Bernd


Am 01.04.2022 um 23:50 schrieb Bernd Oppolzer:

See some answers below.

In general the elimination of base registers for the code section
with existing large programs is a major task and needs careful testing.
I did this sometimes, and I had many issues and headaches, until the
programs worked (again). More hints below ...

Kind regards

Bernd


Am 01.04.2022 um 20:41 schrieb Dave Clark:
"IBM Mainframe Assembler List"  
wrote on

04/01/2022 02:14:38 PM:

Where I disagree is on the base register issue. Base registers and
code addressability issues should have gone away. It is pretty
trivial to replace old branches with their newer relative
counterparts. Should be faster code, too, FWIW.


 OK, I'll bite.  This discussion has probably been done 
before but

I wasn't around for that.  Forgive my newbie questions -- even though I
have been programming in assembler on and off since 1978.  That said...

 I understand relative branching on a basic level.  But I 
haven't
really looked into them and haven't used them at all to this point.  
So...


1. Is it as simple as just using a different mnemonic for the branch?


In general, yes, but, see above, there are different problems,
with IBM or site-specific macros which generate inline definitions etc.
and literals etc. ... and which assume that there is a base register 
which

covers the code section. You can change them, or you can establish a
temporary base (maybe register 1,14, 15) around the macro call.



2. Does the target label still have to be within 4K for the relative
branch?


No, even the simple relative branches can reach 64 k in both directions
from the current PSW



3. ...or is there an extended relative branch that uses the extended
displacement feature?


there are extended branches, but when converting existing programs,
you normally don't need them


4. What about the target for the EXecute instruction?  Is there a 
relative

version of this?


no need for this during normal conversion, because you need a base 
register

for the data part, anyway, and the target of the EX is in the data part


5. Even if code base register(s) is(are) eliminated, you still need a 
data

base register -- yes?


yes, sure. If you read my former post about local procedures, which had
for example two base registers in the past, you may now reduce the
two base registers to one, and the one covers the "local" data area
of the local procedure, which is the data area which lies behind the
code section of the local procedure. The code section doesn't need
a base register any more. With the older technique, both code and
data area were limited to 8 k; now the data area is limited to 4k,
but the code area is unlimited (if you manage to get is baseless).



6. If you have a large program with constant data at the end of the
program, how do you establish the base register needed for that data 
area?


you should IMO move the "global" data after the code section for the
mainline, and then establish a base register from the mainline, which
makes this global data section available for all "local subroutines".
This way, you can access all data with only two base registers,
say 10 and 11: 10 for the global data area, and 11 for all the local
data areas; every local procedures assigns reg 11 to the base address
of its local ares on entry. The addressing of these areas is always
established using address constants.


7. Lastly, if the code base register has been eliminated, does this mean
you should no longer have things like LTORG at the end of each 
subroutine

to force data to be stored near the subroutine that uses it (where
previously the code base register for the subroutine would have served
double-duty as the data base register)?


you need LTORG as before; see above ... you still have a base register
which points at the data area for every subroutine. The difference to
the older solution is that the base address now is not the beginning
of the subroutine but instead somewhere near the end and that
the base register does not cover the code section (and the data section)
but only the data section, which lies behind the code section.
The LTORG should be located directly following the return instructions,
at the end of the 

Re: Eliminating Base Registers (was: Inlining routines)

[Bernd Oppolzer]

See some answers below.

In general the elimination of base registers for the code section
with existing large programs is a major task and needs careful testing.
I did this sometimes, and I had many issues and headaches, until the
programs worked (again). More hints below ...

Kind regards

Bernd


Am 01.04.2022 um 20:41 schrieb Dave Clark:

"IBM Mainframe Assembler List"  wrote on
04/01/2022 02:14:38 PM:

Where I disagree is on the base register issue. Base registers and
code addressability issues should have gone away. It is pretty
trivial to replace old branches with their newer relative
counterparts. Should be faster code, too, FWIW.


 OK, I'll bite.  This discussion has probably been done before but
I wasn't around for that.  Forgive my newbie questions -- even though I
have been programming in assembler on and off since 1978.  That said...

 I understand relative branching on a basic level.  But I haven't
really looked into them and haven't used them at all to this point.  So...

1. Is it as simple as just using a different mnemonic for the branch?


In general, yes, but, see above, there are different problems,
with IBM or site-specific macros which generate inline definitions etc.
and literals etc. ... and which assume that there is a base register which
covers the code section. You can change them, or you can establish a
temporary base (maybe register 1,14, 15) around the macro call.



2. Does the target label still have to be within 4K for the relative
branch?


No, even the simple relative branches can reach 64 k in both directions
from the current PSW



3. ...or is there an extended relative branch that uses the extended
displacement feature?


there are extended branches, but when converting existing programs,
you normally don't need them



4. What about the target for the EXecute instruction?  Is there a relative
version of this?


no need for this during normal conversion, because you need a base register
for the data part, anyway, and the target of the EX is in the data part



5. Even if code base register(s) is(are) eliminated, you still need a data
base register -- yes?


yes, sure. If you read my former post about local procedures, which had
for example two base registers in the past, you may now reduce the
two base registers to one, and the one covers the "local" data area
of the local procedure, which is the data area which lies behind the
code section of the local procedure. The code section doesn't need
a base register any more. With the older technique, both code and
data area were limited to 8 k; now the data area is limited to 4k,
but the code area is unlimited (if you manage to get is baseless).



6. If you have a large program with constant data at the end of the
program, how do you establish the base register needed for that data area?


you should IMO move the "global" data after the code section for the
mainline, and then establish a base register from the mainline, which
makes this global data section available for all "local subroutines".
This way, you can access all data with only two base registers,
say 10 and 11: 10 for the global data area, and 11 for all the local
data areas; every local procedures assigns reg 11 to the base address
of its local ares on entry. The addressing of these areas is always
established using address constants.


7. Lastly, if the code base register has been eliminated, does this mean
you should no longer have things like LTORG at the end of each subroutine
to force data to be stored near the subroutine that uses it (where
previously the code base register for the subroutine would have served
double-duty as the data base register)?


you need LTORG as before; see above ... you still have a base register
which points at the data area for every subroutine. The difference to
the older solution is that the base address now is not the beginning
of the subroutine but instead somewhere near the end and that
the base register does not cover the code section (and the data section)
but only the data section, which lies behind the code section.
The LTORG should be located directly following the return instructions,
at the end of the code section of the subroutine.





Sincerely,

Dave Clark

RES: Eliminating Base Registers (was: Inlining routines)

[João Reginato]

You may use OPSYN to replace instructions to use 20 bits displacement instead 
of 12, and change B to J, for example:

L   OPSYN   LY
LA  OPSYN   LAY
B   OPSYN   J
BL  OPSYN   JL
BE  OPSYN   JE

And so on ...

João

-Mensagem original-
De: IBM Mainframe Assembler List  Em nome de 
Martin Trübner
Enviada em: sexta-feira, 1 de abril de 2022 16:54
Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Assunto: Re: Eliminating Base Registers (was: Inlining routines)

VSE does not have IEABRX(X)

but it has MAKEREL

you can find it on the vmworkshop page


http://workshop.velocitysoftware.com/martin/index.shtml


Martin

Re: Eliminating Base Registers (was: Inlining routines)

[Martin Trübner]

VSE does not have IEABRX(X)

but it has MAKEREL

you can find it on the vmworkshop page


http://workshop.velocitysoftware.com/martin/index.shtml


Martin

Re: Eliminating Base Registers (was: Inlining routines)

[Charles Mills]

I recommend using change in an editor anyway, so you keep control of the
process. YMMV

If you run into IBM or other macro problems, cross that bridge when you come
to it. IEABRCX can be "turned on" and "turned off" at various points in the
source code if necessary. No idea if it is available for VSE, but there is
nothing inherently "z/OS" about it -- pure hardware assembler, I believe. Or
you could roll your own.

Is there anything like the SYSSTATE ARCHLVL= macro in VSE? *Some* IBM macros
are responsive to it and will generate relative branches "natively" if you
are at a sufficient level.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Dave Clark
Sent: Friday, April 1, 2022 12:32 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Eliminating Base Registers (was: Inlining routines)

"IBM Mainframe Assembler List"  wrote on 
04/01/2022 02:51:13 PM:
> some brief comments:
> plus IBM macros have to be converted, there should be a macro to do that


Thanks.  I did some reading at the link subsequently sent to this 
and I checked my system.  Apparently that macro (IEABRCX) was not made 
available to the z/VSE mainframe environment -- at least, not at my level. 
 We are 10 or 12 years behind on upgrades.   ;-)We will be upgrading 
to the latest level in the next two months, though, and I can check again.


Sincerely,

Dave Clark
-- 
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331






*
This email message and any attachments is for use only by the named 
addressee(s) and may contain confidential, privileged and/or proprietary 
information. If you have received this message in error, please 
immediately notify the sender and delete and destroy the message and all 
copies. All unauthorized direct or indirect use or disclosure of this 
message is strictly prohibited. No right to confidentiality or privilege 
is waived or lost by any error in transmission. 

*

Re: Eliminating Base Registers (was: Inlining routines)

[Dave Clark]

"IBM Mainframe Assembler List"  wrote on 
04/01/2022 03:32:42 PM:
> Just go for it! Relative branches are 100% goodness, the best thing in
> assembler since ICM. Easy as pi. 
> 
> Find a B opcode and replace it with a J. Find a BE opcode and replace it
> with a JE. Convince yourself of how easy this is going to be, and then 
just
> do it.
> 
> Only classic B SOMELABEL branches. J does not replace branch table 
branches
> like B 4(R1,R15) or B FOOBAR(R2). 


I generally don't use the last two forms of branching so I am good 
from that standpoint.  My recent project (external assembler REXX function 
for VSAM I/O) is what got me thinking more seriously about eliminating the 
need for code base registers.  The main routine links three base registers 
to cover the code and trailing constants -- in spite of splitting out to 
four other external subroutines to get everything done.  Losing the more 
general use of three registers really hurt.   ;-)


Sincerely,

Dave Clark
-- 
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331




*
This email message and any attachments is for use only by the named 
addressee(s) and may contain confidential, privileged and/or proprietary 
information. If you have received this message in error, please 
immediately notify the sender and delete and destroy the message and all 
copies. All unauthorized direct or indirect use or disclosure of this 
message is strictly prohibited. No right to confidentiality or privilege 
is waived or lost by any error in transmission. 
*

Re: Eliminating Base Registers (was: Inlining routines)

[Charles Mills]

Just go for it! Relative branches are 100% goodness, the best thing in
assembler since ICM. Easy as pi. 

Find a B opcode and replace it with a J. Find a BE opcode and replace it
with a JE. Convince yourself of how easy this is going to be, and then just
do it.

Only classic B SOMELABEL branches. J does not replace branch table branches
like B 4(R1,R15) or B FOOBAR(R2). 

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Dave Clark
Sent: Friday, April 1, 2022 11:42 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Eliminating Base Registers (was: Inlining routines)

"IBM Mainframe Assembler List"  wrote on 
04/01/2022 02:14:38 PM:
> Where I disagree is on the base register issue. Base registers and 
> code addressability issues should have gone away. It is pretty 
> trivial to replace old branches with their newer relative 
> counterparts. Should be faster code, too, FWIW.


OK, I'll bite.  This discussion has probably been done before but 
I wasn't around for that.  Forgive my newbie questions -- even though I 
have been programming in assembler on and off since 1978.  That said...

I understand relative branching on a basic level.  But I haven't 
really looked into them and haven't used them at all to this point.  So...

1. Is it as simple as just using a different mnemonic for the branch?
2. Does the target label still have to be within 4K for the relative 
branch?
3. ...or is there an extended relative branch that uses the extended 
displacement feature?
4. What about the target for the EXecute instruction?  Is there a relative 
version of this?
5. Even if code base register(s) is(are) eliminated, you still need a data 
base register -- yes?
6. If you have a large program with constant data at the end of the 
program, how do you establish the base register needed for that data area?
7. Lastly, if the code base register has been eliminated, does this mean 
you should no longer have things like LTORG at the end of each subroutine 
to force data to be stored near the subroutine that uses it (where 
previously the code base register for the subroutine would have served 
double-duty as the data base register)?


Sincerely,

Dave Clark
-- 
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331






*
This email message and any attachments is for use only by the named 
addressee(s) and may contain confidential, privileged and/or proprietary 
information. If you have received this message in error, please 
immediately notify the sender and delete and destroy the message and all 
copies. All unauthorized direct or indirect use or disclosure of this 
message is strictly prohibited. No right to confidentiality or privilege 
is waived or lost by any error in transmission. 

*

Re: Eliminating Base Registers (was: Inlining routines)

[Dave Clark]

"IBM Mainframe Assembler List"  wrote on 
04/01/2022 02:51:13 PM:
> some brief comments:
> plus IBM macros have to be converted, there should be a macro to do that


Thanks.  I did some reading at the link subsequently sent to this 
and I checked my system.  Apparently that macro (IEABRCX) was not made 
available to the z/VSE mainframe environment -- at least, not at my level. 
 We are 10 or 12 years behind on upgrades.   ;-)We will be upgrading 
to the latest level in the next two months, though, and I can check again.


Sincerely,

Dave Clark
-- 
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331





*
This email message and any attachments is for use only by the named 
addressee(s) and may contain confidential, privileged and/or proprietary 
information. If you have received this message in error, please 
immediately notify the sender and delete and destroy the message and all 
copies. All unauthorized direct or indirect use or disclosure of this 
message is strictly prohibited. No right to confidentiality or privilege 
is waived or lost by any error in transmission. 
*

Re: Eliminating Base Registers (was: Inlining routines)

[Charles Mills]

Don't use IEABRCX with LE-enabled assembler! There is (or was -- perhaps
they fixed it) a dependency on opcode 47 in EDCPRLG. 

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Friday, April 1, 2022 11:59 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Eliminating Base Registers (was: Inlining routines)

On Apr 1, 2022, at 12:51:13, Gary Weinhold wrote:
> 
> some brief comments:
> plus IBM macros have to be converted, there should be a macro to do that
> 
<https://www.ibm.com/docs/en/zos/2.5.0?topic=xct-ieabrcx-relative-branch-mac
ro-extension>

> On 2022-04-01 2:41 p.m., Dave Clark wrote:
>> "IBM Mainframe Assembler List"  wrote on
>> 04/01/2022 02:14:38 PM:
>>> Where I disagree is on the base register issue. Base registers and
>>> code addressability issues should have gone away. It is pretty
>>> trivial to replace old branches with their newer relative
>>> counterparts. Should be faster code, too, FWIW.
>> 
>>OK, I'll bite.  This discussion has probably been done before but
>> I wasn't around for that.  Forgive my newbie questions -- even though I
>> have been programming in assembler on and off since 1978.  That said...

-- 
gil

Re: Eliminating Base Registers (was: Inlining routines)

[Paul Gilmartin]

On Apr 1, 2022, at 12:51:13, Gary Weinhold wrote:
> 
> some brief comments:
> plus IBM macros have to be converted, there should be a macro to do that
> 


> On 2022-04-01 2:41 p.m., Dave Clark wrote:
>> "IBM Mainframe Assembler List"  wrote on
>> 04/01/2022 02:14:38 PM:
>>> Where I disagree is on the base register issue. Base registers and
>>> code addressability issues should have gone away. It is pretty
>>> trivial to replace old branches with their newer relative
>>> counterparts. Should be faster code, too, FWIW.
>> 
>>OK, I'll bite.  This discussion has probably been done before but
>> I wasn't around for that.  Forgive my newbie questions -- even though I
>> have been programming in assembler on and off since 1978.  That said...

-- 
gil

Re: Eliminating Base Registers (was: Inlining routines)

[Charles Mills]

1. Pretty much. So much so that there is an IBM supplied macro that will
just do a 1 for 1 mindless replacement. I recommend using change in a text
editor instead but YMMV.

2. No. I have forgotten the range because it has never bitten me. +/-65K?
Someone will correct me.

3. I believe so. Never used it. The link editor is smart enough that you can
jump from one module to another, believe it or not.

4. Yes, but newer than the relative branches. Check the ARCH level to be
sure you have it.

5. Yes, but IMHO likely to be less of a problem.

6. I use LOCTR to take things that I define late in the source code and put
them at the front of the object code. Pretty simple.

7. Best for performance to move data more than 256 bytes away from code, and
to keep code as compact as possible. In other words, data with data,
instructions with instructions. Read-only data with read-only data,
read-write data with read-write data.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Dave Clark
Sent: Friday, April 1, 2022 11:42 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Eliminating Base Registers (was: Inlining routines)

"IBM Mainframe Assembler List"  wrote on 
04/01/2022 02:14:38 PM:
> Where I disagree is on the base register issue. Base registers and 
> code addressability issues should have gone away. It is pretty 
> trivial to replace old branches with their newer relative 
> counterparts. Should be faster code, too, FWIW.


OK, I'll bite.  This discussion has probably been done before but 
I wasn't around for that.  Forgive my newbie questions -- even though I 
have been programming in assembler on and off since 1978.  That said...

I understand relative branching on a basic level.  But I haven't 
really looked into them and haven't used them at all to this point.  So...

1. Is it as simple as just using a different mnemonic for the branch?
2. Does the target label still have to be within 4K for the relative 
branch?
3. ...or is there an extended relative branch that uses the extended 
displacement feature?
4. What about the target for the EXecute instruction?  Is there a relative 
version of this?
5. Even if code base register(s) is(are) eliminated, you still need a data 
base register -- yes?
6. If you have a large program with constant data at the end of the 
program, how do you establish the base register needed for that data area?
7. Lastly, if the code base register has been eliminated, does this mean 
you should no longer have things like LTORG at the end of each subroutine 
to force data to be stored near the subroutine that uses it (where 
previously the code base register for the subroutine would have served 
double-duty as the data base register)?


Sincerely,

Dave Clark
-- 
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331






*
This email message and any attachments is for use only by the named 
addressee(s) and may contain confidential, privileged and/or proprietary 
information. If you have received this message in error, please 
immediately notify the sender and delete and destroy the message and all 
copies. All unauthorized direct or indirect use or disclosure of this 
message is strictly prohibited. No right to confidentiality or privilege 
is waived or lost by any error in transmission. 

*

Re: Eliminating Base Registers (was: Inlining routines)

[Gary Weinhold]

some brief comments:
plus IBM macros have to be converted, there should be a macro to do that

On 2022-04-01 2:41 p.m., Dave Clark wrote:

"IBM Mainframe Assembler List"  wrote on
04/01/2022 02:14:38 PM:

Where I disagree is on the base register issue. Base registers and
code addressability issues should have gone away. It is pretty
trivial to replace old branches with their newer relative
counterparts. Should be faster code, too, FWIW.


 OK, I'll bite.  This discussion has probably been done before but
I wasn't around for that.  Forgive my newbie questions -- even though I
have been programming in assembler on and off since 1978.  That said...

 I understand relative branching on a basic level.  But I haven't
really looked into them and haven't used them at all to this point.  So...

1. Is it as simple as just using a different mnemonic for the branch?

Yes

2. Does the target label still have to be within 4K for the relative
branch?

No

3. ...or is there an extended relative branch that uses the extended
displacement feature?

The default is extended

4. What about the target for the EXecute instruction?  Is there a relative
version of this?

EXRL

5. Even if code base register(s) is(are) eliminated, you still need a data
base register -- yes?

Reentrant, of course; there are some relative data reference commands

6. If you have a large program with constant data at the end of the
program, how do you establish the base register needed for that data area?

LARL will get the address

7. Lastly, if the code base register has been eliminated, does this mean
you should no longer have things like LTORG at the end of each subroutine
to force data to be stored near the subroutine that uses it (where
previously the code base register for the subroutine would have served
double-duty as the data base register)?

Yes but more immediate instructions may mean less need for literals



Sincerely,

Dave Clark


Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: weinh...@dkl.com
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.

Eliminating Base Registers (was: Inlining routines)

[Dave Clark]

"IBM Mainframe Assembler List"  wrote on 
04/01/2022 02:14:38 PM:
> Where I disagree is on the base register issue. Base registers and 
> code addressability issues should have gone away. It is pretty 
> trivial to replace old branches with their newer relative 
> counterparts. Should be faster code, too, FWIW.


OK, I'll bite.  This discussion has probably been done before but 
I wasn't around for that.  Forgive my newbie questions -- even though I 
have been programming in assembler on and off since 1978.  That said...

I understand relative branching on a basic level.  But I haven't 
really looked into them and haven't used them at all to this point.  So...

1. Is it as simple as just using a different mnemonic for the branch?
2. Does the target label still have to be within 4K for the relative 
branch?
3. ...or is there an extended relative branch that uses the extended 
displacement feature?
4. What about the target for the EXecute instruction?  Is there a relative 
version of this?
5. Even if code base register(s) is(are) eliminated, you still need a data 
base register -- yes?
6. If you have a large program with constant data at the end of the 
program, how do you establish the base register needed for that data area?
7. Lastly, if the code base register has been eliminated, does this mean 
you should no longer have things like LTORG at the end of each subroutine 
to force data to be stored near the subroutine that uses it (where 
previously the code base register for the subroutine would have served 
double-duty as the data base register)?


Sincerely,

Dave Clark
-- 
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331





*
This email message and any attachments is for use only by the named 
addressee(s) and may contain confidential, privileged and/or proprietary 
information. If you have received this message in error, please 
immediately notify the sender and delete and destroy the message and all 
copies. All unauthorized direct or indirect use or disclosure of this 
message is strictly prohibited. No right to confidentiality or privilege 
is waived or lost by any error in transmission. 
*

Re: Inlining routines

[Schmitt, Michael]

I'm thinking this might work...


 Instruction
 Instruction
do_b0100 equ * the sub call is replaced by a label
 org *+b0100_sub_len   and an org that leaves a hole the size of 
the inlined code
 Instruction

 :
 :

 org   do_b0100the subroutine entry ORGs to where it was 
called
b0100_edit_parms ds 0h and has a starting label
 instructions...
 :
 :
b0100_exit equ *
b0100_sub_len equ *-b0100_edit_parmsthe subroutine exit calculates the 
length of the routine
 organd orgs back to normal


It seemed to assemble correctly.

But I agree. I'm being clever to save a total of 2 J instructions, since the 
macro now does J to the routine and then J back to the call + 4.



-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Charles Mills
Sent: Friday, April 1, 2022 1:15 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Inlining routines

I half agree with Bernd.

I would say that unless the code is executed a million times a day (literally) 
then the inline macro approach is too clever.

Compilers have the advantage that they automatically "adjust" things on every 
compile, so if suddenly the optimization logic thinks the subroutine is better 
out-of-line, it can just do that, with no labor cost and no risk of mucking 
something up.

Also agree on small modules. Small modules rule!

Where I disagree is on the base register issue. Base registers and code 
addressability issues should have gone away. It is pretty trivial to replace 
old branches with their newer relative counterparts. Should be faster code, 
too, FWIW.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Bernd Oppolzer
Sent: Friday, April 1, 2022 10:34 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Inlining routines

While in theory something like that could be possible, I would recommend
not to do it.

The objective of inlining comes from higher level languages, where the
cost of subroutine
linkage is high, because of local variables, possibly recursive calls
(stack management) etc.
And maybe there are very small functions and procedures, which are
called very often.

With ASSEMBLER, the cost should be lower.

OTOH, you have a big problem, if your code pieces are large, due to base
register and
addressing concerns. For example: I am managing a large (old) ASSEMBLER
application system
at the moment. It has some test (trace) macros in it, which I can
activate, when needed,
using some global SET symbols. But some modules, when I do this (or when
I add new
test output for diagnosis purposes), run into adressibility issues. So
it is much better
to break the code into separately managed pieces which are smaller and
which have
base registers of their own (or, of course, convert them to baseless
technique,
but this is a large effort).

Re: Inlining routines

[Charles Mills]

I half agree with Bernd.

I would say that unless the code is executed a million times a day (literally) 
then the inline macro approach is too clever.

Compilers have the advantage that they automatically "adjust" things on every 
compile, so if suddenly the optimization logic thinks the subroutine is better 
out-of-line, it can just do that, with no labor cost and no risk of mucking 
something up.

Also agree on small modules. Small modules rule!

Where I disagree is on the base register issue. Base registers and code 
addressability issues should have gone away. It is pretty trivial to replace 
old branches with their newer relative counterparts. Should be faster code, 
too, FWIW.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Bernd Oppolzer
Sent: Friday, April 1, 2022 10:34 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Inlining routines

While in theory something like that could be possible, I would recommend 
not to do it.

The objective of inlining comes from higher level languages, where the 
cost of subroutine
linkage is high, because of local variables, possibly recursive calls 
(stack management) etc.
And maybe there are very small functions and procedures, which are 
called very often.

With ASSEMBLER, the cost should be lower.

OTOH, you have a big problem, if your code pieces are large, due to base 
register and
addressing concerns. For example: I am managing a large (old) ASSEMBLER 
application system
at the moment. It has some test (trace) macros in it, which I can 
activate, when needed,
using some global SET symbols. But some modules, when I do this (or when 
I add new
test output for diagnosis purposes), run into adressibility issues. So 
it is much better
to break the code into separately managed pieces which are smaller and 
which have
base registers of their own (or, of course, convert them to baseless 
technique,
but this is a large effort).

Re: Inlining routines

[Bernd Oppolzer]

While in theory something like that could be possible, I would recommend 
not to do it.


The objective of inlining comes from higher level languages, where the 
cost of subroutine
linkage is high, because of local variables, possibly recursive calls 
(stack management) etc.
And maybe there are very small functions and procedures, which are 
called very often.


With ASSEMBLER, the cost should be lower.

OTOH, you have a big problem, if your code pieces are large, due to base 
register and
addressing concerns. For example: I am managing a large (old) ASSEMBLER 
application system
at the moment. It has some test (trace) macros in it, which I can 
activate, when needed,
using some global SET symbols. But some modules, when I do this (or when 
I add new
test output for diagnosis purposes), run into adressibility issues. So 
it is much better
to break the code into separately managed pieces which are smaller and 
which have
base registers of their own (or, of course, convert them to baseless 
technique,

but this is a large effort).

In any case, a large monolithic piece of (executable) ASSEMBLER code is
a nightmare. You need well structured smaller separated pieces which 
represent some

sort of "business functions", otherwise you will not be able to manage the
complexity, which, IMO, grows much more than linear with the size of a 
monolithic
piece of software. You can do calls simply by using BAS or JAS and only 
save

all or some of the registers ... that's all (two machine instructions and
a save area).

For my current customer, I wrote (or improved) global macros to support
the inline "procedure" calls. These lightweight procedure calls save the
registers (as desired), etablish a new base register (or two) and do things
like LTORG at the end and take care of SIIS problems or - if desired -
RENT requirements. All with two or three machine instructions on
entry and on exit. This is NOT for external linkage, but for the
internal structure of (large) ASSEMBLER modules, having in theory
many 4 k blocks of code size (and much more than 10.000 lines of code) ...
but still manageable, because they consist of small code blocks,
which can be tested and veryfied separately.

HTH, kind regards

Bernd



Am 01.04.2022 um 17:52 schrieb Schmitt, Michael:

I like to code in assembler as well-structured, even though that's not the 
maximum possible efficiency. For example, I'll break up the program into 
subroutines even when the subroutine is only executed from one place.

In COBOL this actually is optimal, since the optimizer will inline the 
instructions. You get the benefit of an easy to understand and maintain program 
with no loss in performance.

In assembler, the oldest programs I inherited still used BAL logic for such 
routines, with a register save area. Later code may use a BAS/JAS with a 
register but not save the register, if that register isn't needed by the 
subroutine.

Now I have subroutine macros that will call and return from such routine using 
a Jump.

What I'm wondering is, is there a reasonable way to have HLASM inline the code?

I mean, the code would be written as:

Instruction
Instruction
* here's where I want to insert ROUTINE_A
Instruction

  :
  :

ROUTINE_A EQU *
Routine A's instructions
*end of routine A

But it would assemble routine A in the place in the instruction stream where it was 
"called".

I'm thinking it should be possible with LOCTR but I've never actually used 
that, and it isn't clear how.

Note: If I were to actually do this, I'd do it by having the subroutine 
entry/exit/call macros generate the desired code.

Re: Inlining routines

[Dave Clark]

"IBM Mainframe Assembler List"  wrote on 
04/01/2022 12:40:09 PM:
> You could put the inline code in a macro rather than in a copy member 
and
> put the macro in the source code itself.


Yep, that is exactly what I said in the second paragraph of my 
post.


Sincerely,

Dave Clark
-- 
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331





*
This email message and any attachments is for use only by the named 
addressee(s) and may contain confidential, privileged and/or proprietary 
information. If you have received this message in error, please 
immediately notify the sender and delete and destroy the message and all 
copies. All unauthorized direct or indirect use or disclosure of this 
message is strictly prohibited. No right to confidentiality or privilege 
is waived or lost by any error in transmission. 
*

Re: Inlining routines

[Charles Mills]

You could put the inline code in a macro rather than in a copy member and
put the macro in the source code itself.

The macro could have a parameter TYPE=CALLED or TYPE=INLINE.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Dave Clark
Sent: Friday, April 1, 2022 9:26 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Inlining routines

"IBM Mainframe Assembler List"  wrote on 
04/01/2022 11:52:54 AM:
> What I'm wondering is, is there a reasonable way to have HLASM 
> inline the code?
> 
> I mean, the code would be written as:
> 
> Instruction
> Instruction
> * here's where I want to insert ROUTINE_A
> Instruction
> 
>  :
>  :
> 
> ROUTINE_A EQU *
> Routine A's instructions
> *end of routine A
> 
> But it would assemble routine A in the place in the instruction 
> stream where it was "called".


Essentially, what you're describing is what I call a "code 
snippet" and I put such things in a copybook.  Thus, they would always be 
used in-line no matter how many times they were included in the program 
source.  As an alternative, to reduce program size, you can wrap the same 
copybook with subroutine code in order to formally "call" it from multiple 
places in the program.  Thus, the same copybook can serve in two different 
ways.

However, I do understand the "loss" of being able to maintain the 
code snippet in the same source code member.  The code copybook would have 
to be maintained as a separate member.  The alternative is to make the 
code snippet into a macro and leave the macro source in the main program 
source so that they can be maintained together in a single member.


Sincerely,

Dave Clark
-- 
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331





*
This email message and any attachments is for use only by the named 
addressee(s) and may contain confidential, privileged and/or proprietary 
information. If you have received this message in error, please 
immediately notify the sender and delete and destroy the message and all 
copies. All unauthorized direct or indirect use or disclosure of this 
message is strictly prohibited. No right to confidentiality or privilege 
is waived or lost by any error in transmission. 

*

Re: Inlining routines

[Dave Clark]

"IBM Mainframe Assembler List"  wrote on 
04/01/2022 11:52:54 AM:
> What I'm wondering is, is there a reasonable way to have HLASM 
> inline the code?
> 
> I mean, the code would be written as:
> 
> Instruction
> Instruction
> * here's where I want to insert ROUTINE_A
> Instruction
> 
>  :
>  :
> 
> ROUTINE_A EQU *
> Routine A's instructions
> *end of routine A
> 
> But it would assemble routine A in the place in the instruction 
> stream where it was "called".


Essentially, what you're describing is what I call a "code 
snippet" and I put such things in a copybook.  Thus, they would always be 
used in-line no matter how many times they were included in the program 
source.  As an alternative, to reduce program size, you can wrap the same 
copybook with subroutine code in order to formally "call" it from multiple 
places in the program.  Thus, the same copybook can serve in two different 
ways.

However, I do understand the "loss" of being able to maintain the 
code snippet in the same source code member.  The code copybook would have 
to be maintained as a separate member.  The alternative is to make the 
code snippet into a macro and leave the macro source in the main program 
source so that they can be maintained together in a single member.


Sincerely,

Dave Clark
-- 
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331




*
This email message and any attachments is for use only by the named 
addressee(s) and may contain confidential, privileged and/or proprietary 
information. If you have received this message in error, please 
immediately notify the sender and delete and destroy the message and all 
copies. All unauthorized direct or indirect use or disclosure of this 
message is strictly prohibited. No right to confidentiality or privilege 
is waived or lost by any error in transmission. 
*

Inlining routines

[Schmitt, Michael]

I like to code in assembler as well-structured, even though that's not the 
maximum possible efficiency. For example, I'll break up the program into 
subroutines even when the subroutine is only executed from one place.

In COBOL this actually is optimal, since the optimizer will inline the 
instructions. You get the benefit of an easy to understand and maintain program 
with no loss in performance.

In assembler, the oldest programs I inherited still used BAL logic for such 
routines, with a register save area. Later code may use a BAS/JAS with a 
register but not save the register, if that register isn't needed by the 
subroutine.

Now I have subroutine macros that will call and return from such routine using 
a Jump.

What I'm wondering is, is there a reasonable way to have HLASM inline the code?

I mean, the code would be written as:

Instruction
Instruction
* here's where I want to insert ROUTINE_A
Instruction

 :
 :

ROUTINE_A EQU *
Routine A's instructions
*end of routine A

But it would assemble routine A in the place in the instruction stream where it 
was "called".

I'm thinking it should be possible with LOCTR but I've never actually used 
that, and it isn't clear how.

Note: If I were to actually do this, I'd do it by having the subroutine 
entry/exit/call macros generate the desired code.