Thank you, I found the solution myself - dependent USINGs -
see Chapter XI of Dr. John Ehrman's excellent book "Assembler Language
Programming ..."
Have a nice day,
kind regards
Bernd
Am 06.04.2021 um 00:17 schrieb Bernd Oppolzer:
Hello ASSEMBLER list,
I have a problem which is difficult to explain,
let me give it a try ...
I am rewriting old ASSEMBLER modules which have SIIS problems.
There are customer written macros which have inline parameter lists
which are modified, which leads to SIIS performance problems.
One elegant soluton is: the customer macros can generate reentrant code,
if a global switch is set. If so, they put all their variable parts in
a certain (global) DSECT
called #DRENT, and a dynamic area for this DSECT is obtained by the
startup macro.
The nice thing about this is that the total size of this DSECT is
computed automatically
at the end by the ASSEMBLER and the startup macro can obtain the
needed area size.
(The #DRENT DSECT is addressed using register 13 with reentrant programs,
and it simply is the area following the system save area, so there is
no special
register needed to address it in the reentrant case).
I now decided to use this mechanism to get rid of the SIIS problems;
I simply set the global switch to YES, although the programs are NORENT,
and then define a "static #DRENT", much like this
#DRENT_STATIC DS CL(#END_OF_DRENT-#DRENT)
then I have to find a free register and identify the register with the
"static #DRENT"
by a USING instruction. (Register 13 is not possible in this case,
because it is already
occupied by the system save area in the startup macro, and this area
cannot be extended).
That is: I am cheating; the customer macros "think" they have to
generate code
for the reentrant case.
This way, the SIIS problems disappear, because now the stores etc.
have a distance
big enough from the PSW position. It works, and in some processes, I have
performance gains of 6 percent and more. And there is almost no change
to the
customer modules (only two new macro calls, and all SIIS problems in
all macro
calls throughout the whole module disappear).
Now my problem:
with several large programs, it is not easy to find a free register
for the "static #DRENT".
But: there are registers which access the static area of the program,
that is,
the area where the static definitions and the constants reside.
say: register 10 is the base for those static definitions and constants.
and: let's assume that the new "static #DRENT" can be positioned at
the very beginning
of this static and constant area
How can I convince the ASSEMBLER to use register 10 during translation
for
both the #DRENT DSECT (inside the customer macros) and the static area
(in the open code)? Is this possible? Is there a solution using new
ASSEMBLER
techniques like LOCTR etc.?
I don't want to change the customer macros, because they are used in
1000s of other
modules; only changes to the open code, if possible ...
Thank you, kind regards
Bernd
--
Oppolzer-Informatik
Dipl. Inf. Bernd Oppolzer
Bärenhofstraße 23
70771 Leinfelden-Echterdingen
—————————————————————
Tel.: +49 711 7949591
priv.: +49 711 7949590
mobil: +49 151 75005359
eMail: [email protected] <mailto:[email protected]>
Web: http://bernd-oppolzer.de/job.htm <http://bernd-oppolzer.de/job.htm>
—————————————————————
Für Umsatzsteuerzwecke:
SteuerNr.: 97 076 / 29921
USt-ID-Nr.: DE 147 700 393
—————————————————————
Oppolzer-Informatik 1983 - 2021
38 years of experience in computer science**
