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).
