Re LRL: The architecture doesn't enforce non-modifiabilty of your code, and not all instructions have to be equally useful. HLASM dies allow more flexiblity in defining a storage constant than it does for an immediate operand, but that's no excuse. Sorry, that's all I've got; generally I agree with you.
Re LGFI: The LFI instruction is named IILF. Maybe HLASM should add an extended mnemonic for it. sas On Mon, May 3, 2021 at 1:17 PM Tony Harminc <[email protected]> wrote: > On a more general topic, why does LRL exist in the first place? Why > would any programmer (or compiler) use LRL in preference to IILF or > one of the other immediate instructions? (And why is there LGFI but no > LFI?) > > Surely immediate instructions are generally faster than relative ones. > Some of them are longer, but not in this case. Yes, of course the > storage operand of LRL can change in a way that the immediate operand > of IILF is unlikely to. But still, without extreme Binder tricks, I > can't think that an operand that's at a fixed relative distance from > the instruction is likely to be able to be placed in dynamic storage > while the instruction isn't. > > Does someone have a use case for LRL? > > Tony H. >
