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_b0100 the 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_parms the subroutine exit calculates the
length of the routine
org and 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 <[email protected]> On Behalf
Of Charles Mills
Sent: Friday, April 1, 2022 1:15 PM
To: [email protected]
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:[email protected]] On
Behalf Of Bernd Oppolzer
Sent: Friday, April 1, 2022 10:34 AM
To: [email protected]
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).
