Paging? The conventional wisdom has always been to stay within one base 
register, so for systems with 4K pages that isn't an issue. I tend to use LOCTR 
so that constants aren't always at the end of the source code. I normally put 
labels on the same line as the instructions and inserting code has never been a 
problem. I will admit to using self-modifying code when I was a callow youth, 
but I stopped doing that and started making any new code reentrant and 
refreshable sometime around the end of the 1960s.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of MELVYN MALTZ [0000072265160664-dmarc-requ...@listserv.uga.edu]
Sent: Tuesday, June 2, 2020 4:01 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels

Hi Guys,

I thought I would put my 2 cents worth in
I know that 55 years of Assembler coding doesn't count for much these days
:-)

Labels...
Even back in the 60's I was taught never to put a label on an instruction
I only break that rule now for the subject of an EX (and its variants)
In the old days of real storage I used to code label EQU * and this was fine

Then paging came along and the recommendation was to keep in-line data close
to the instructions using it (locality of reference). As people have
mentioned this sometimes resulted in odd addresses and S0C1 abends (before
unalignment was detected)

So I switched to label DS 0H in coding
Have to state the obvious...DS 0H might not be appropriate for some data as
there are now many instructions that rely on specific alignments

I consider...
         DS     0H
label EQU *
to be overkill and I would deduct 2 points

With changes in architecture, we now move in-line data to avoid cache
problems
And did you know that this code...popular in ancient times is a performance
disaster now
ONETIME NOP THERE
                   MVI  ONETIME+1,X'F0'

Returning CC from a subroutine...
Have to point out that IBM do this in the VSAM TESTCB macro

Melvyn Maltz.

----- Original Message -----
From: "David Woolbright" <woolbright_da...@columbusstate.edu>
To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU>
Sent: Tuesday, June 02, 2020 5:58 PM
Subject: Re: z/OS HLASM: EQU for statement labels


I’’m just a humble academic so I hesitate to weigh in.  I trained assembler
programmers for one large credit card processing company for many years and
their standard was to use EQU * as the target of all branches, mainly so new
lines could be added easily. I’ve never had an odd address created
accidentally using this technique, but it’s also the case that the assembler
will warn you in cases where you do have an unfavorable address. I’m in the
process of revising many years of teaching material into book format, so
your opinions on this matter to me.  Using EQU for targets would seem to be
a stylistic point on which reasonable people could disagree, but perhaps I’m
wrong.

> On Jun 2, 2020, at 11:49 AM, Seymour J Metz <sme...@gmu.edu> wrote:
>
>> Is this useful?
>
> Only if you're a sadist.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> ________________________________________
> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
> behalf of Paul Gilmartin [00000014e0e4a59b-dmarc-requ...@listserv.uga.edu]
> Sent: Tuesday, June 2, 2020 11:40 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: z/OS HLASM: EQU for statement labels
>
> On 2020-06-02, at 09:33:48, Charles Mills wrote:
>>
>> I don't claim any benefit to the technique, it's just my habit. Actually
>> I think the cleanest is a DS 0H followed by label EQU *. That clearly
>> shows what is going on: re-establishing halfword alignment followed by
>> mapping a label to an address.
>>
> I found it ironic that:
> LABEL    CNOP  ...
> assigns the address of the beginning of the padding rather
> than the end to LABEL.  Is this useful?
>
> Fortunately,
> LABEL    DS    0H
> does the opposite so your 2-instruction construct is otiose.
>
> -- gil

Reply via email to