A faster replacement for L R15,=A(EXTRN)

[Don Higgins]

All



With the recent HLASM and z390 support for 32 bit relocatible immediate
fields, it appears that for amode 31, the IILF insert immediate instruction
is a more efficient way to load a register with an external address than
using the traditional L load instruction to fetch an address constant. The
6 byte insert immediate instruction can replace 8 bytes for the load and
address constant. And the insert instruction avoids having to add base and
displacement address and then load the separate address constant.



Don Higgins

d...@higgins.net <mailto:d...@higgins.net>

www.donhiggins.org <http://www.don-higgins.net/>

[Charles Mills]

There was a thread here. What you say is utterly logically correct but I
think the assembler may have some issue with relocatable externs in IILF.
Perhaps that is what you are referring to when you say "recent HLASM
support."

I believe LARL works however, but requires the "new" object file format.

This is from memory. Too lazy to search or experiment.

A simpler change would be to change the =A(extrn) into a constant that is
adjacent to other fields that should already be in cache -- in which case
the L will essentially take no time at all.

I would also add the usual disclaimer: unless this is incredibly
time-sensitive code that gets executed millions of times a day, it is going
to take a lot of years for IILR or LARL to save enough CPU time to recover
the time spent re-assembling and testing your code a couple of times.

OTOH, it is perhaps an interesting pursuit intellectually.

Charles

[Gord Tomlin]

On 2021-01-15 11:27 AM, Don Higgins wrote:
> With the recent HLASM and z390 support for 32 bit relocatible immediate
> fields, it appears that for amode 31, the IILF insert immediate instruction
> is a more efficient way to load a register with an external address than
> using the traditional L load instruction to fetch an address constant. The
> 6 byte insert immediate instruction can replace 8 bytes for the load and
> address constant. And the insert instruction avoids having to add base and
> displacement address and then load the separate address constant.

It's been possible to achieve the same result with LARL for many years (requires the use of the GOFF option in the HLASM parameters).

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

[Farley, Peter x23353]

LARL does NOT require GOFF format assembler output. I have many assembler subroutines using LARL that generate normal 360/370/390 object records and linked into PDS's (not PDSE's).

There are assembler features that require GOFF format, but not LARL on its own.

Peter

-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Gord Tomlin
Sent: Friday, January 15, 2021 11:55 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: A faster replacement for L R15,=A(EXTRN)

On 2021-01-15 11:27 AM, Don Higgins wrote:
> With the recent HLASM and z390 support for 32 bit relocatible
> immediate fields, it appears that for amode 31, the IILF insert
> immediate instruction is a more efficient way to load a register with
> an external address than using the traditional L load instruction to
> fetch an address constant. The
> 6 byte insert immediate instruction can replace 8 bytes for the load
> and address constant. And the insert instruction avoids having to add
> base and displacement address and then load the separate address constant.

It's been possible to achieve the same result with LARL for many years (requires the use of the GOFF option in the HLASM parameters).

--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Steve Smith]

LARL for EXTRN does not require GOFF. It requires the binder, the old
linkage editor can't handle it.

sas

On Fri, Jan 15, 2021 at 11:55 AM Gord Tomlin <
gt.ibm...@actionsoftware.com> wrote:

> On 2021-01-15 11:27 AM, Don Higgins wrote:

> ...

[Gord Tomlin]

On 2021-01-15 11:55 AM, Gord Tomlin wrote:
> It's been possible to achieve the same result with LARL for many years
> (requires the use of the GOFF option in the HLASM parameters).

Since I got called out on the above, I ran some tests to refresh my memory.

The following code:

         EXTRN FOO
         LARL  R15,FOO

assembles cleanly with the GOFF option specified, but without GOFF the
following warning message is issued:

** ASMA215W Relative Immediate external relocation in NOGOFF object text
- FOO

Regardless of whether GOFF is specified on the assembly, the output
object module can be used to create a load module in a PDS.

Revised: "It's been possible to achieve the same result with LARL for
many years (a warning message will be issued if GOFF is not specified in

[Farley, Peter x23353]

I stand corrected. I missed the OP's specification (in the subject as well as in the text) of loading EXTERNAL addresses via IILF. EXTERNAL relative adcons do indeed require GOFF.

My uses of LARL to date have all been for in-the-current-CSECT locations.

Peter

-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Gord Tomlin
Sent: Friday, January 15, 2021 1:20 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: A faster replacement for L R15,=A(EXTRN)

On 2021-01-15 11:55 AM, Gord Tomlin wrote:
> It's been possible to achieve the same result with LARL for many years
> (requires the use of the GOFF option in the HLASM parameters).

Since I got called out on the above, I ran some tests to refresh my memory.

The following code:

         EXTRN FOO
         LARL  R15,FOO

assembles cleanly with the GOFF option specified, but without GOFF the following warning message is issued:

** ASMA215W Relative Immediate external relocation in NOGOFF object text
- FOO

Regardless of whether GOFF is specified on the assembly, the output object module can be used to create a load module in a PDS.

Revised: "It's been possible to achieve the same result with LARL for many years (a warning message will be issued if GOFF is not specified in the HLASM parameters)."

--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Steve Smith]

I forgot about ASMA215W because I suppress it. I don't think that message
is valid on z/OS; but I don't know what other considerations there are,
esp. for VSE & VM.

One of the nice things about EXTRN LARL is that there's no relocation to be
done by Program Fetch. One of the less nice things is that every reference
makes the Binder do a bit of fix-up. A common V-con would possibly make
more sense if there are a lot of references (by lot, probably 100s at
least). OTOH, LLILF/IILF of a V-con would have the disadvantages of both.

sas


On Fri, Jan 15, 2021 at 1:20 PM Gord Tomlin <gt.ibm...@actionsoftware.com>
wrote: