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.
