Well, one could argue that "DS" implies a variable, not instructions, and is
therefore inappropriate as something on which to hang an instruction label.
I like the idea of some kind of "instruction" attribute for EQU, with an error
if you branched to a non-instruction symbol. I think I might argue for an EQU
operand rather than a new opcode, but that is a quibble.
J NEXTL
DC CL(oddnumber)' '
NEXTL INSTRUCT
You know that data mixed with instructions is just a performance KILLER on
modern CPUs? They have separate i- and data caches, and mingling the two makes
a mess that must be straightened out, at a cost of CPU cycles.
Charles
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Keith Moe
Sent: Wednesday, August 1, 2018 12:06 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU * considered harmful
I have been using
label DS 0H
for instruction labels just about forever and will continue to do so until I
retire. That said, the label has the attribute of a half word, not the
attribute of an instruction label. Putting the label on the actual instruction
has the "problem" of inserting code at the label before the existing
instruction, which the separate label simplifies.
That said, I wish the assembler had an "instruction" assembler statement that
could be used to assign labels that would receive the attribute of the
immediate following instruction. It would also force half word alignment if
necessary. Example:
LABEL INSTRUCT
CLI
JNE NEXTL
whatever
J NEXTL
DC CL(oddnumber)' '
NEXTL INSTRUCT
......
The LABEL and NEXTL symbols would be assigned the attribute of the immediately
following instruction (including length of the instruction). The assembler
could then have an option that would flag branch and execute references to
labels that are NOT instructions (and ACONTROL to turn it on and off).
If the first statement the generates something is not an instruction, this
could also be considered a warning situation. In the situation where the
instruction is generated via non-standard means (i.e., DC X'xxxx' because the
Opcode does not have a mnemonic), the ACONTROL function could be used to avoid
the warning.
Keith Moe
BMC Software, Inc.
--------------------------------------------
On Wed, 8/1/18, Gary Weinhold <weinh...@dkl.com> wrote:
Subject: Re: EQU * considered harmful
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Date: Wednesday, August 1, 2018, 11:40 AM
To avoid the problem Dan
illustrates but retain the advantages Charles
cites of not labeling specific instructions, we
use
label
DS 0H instead
of label EQU *
But i think some of the point
of the original post was lost, since the
question was whether
label EQU *
was ever beneficial, where the "*"
indicates current location rather
than
meaning generically any value.
On 2018-08-01 2:23 PM, Dan Greiner wrote:
> I too disagree (rather strongly).
>
> As an example,
consider where EQU is used to give names to bits of a field
in memory.
>
> FLAGS
DS X
> F_OPEN EQU
X'80'
> F_CLOSE EQU
X'40'
> F_FUBAR EQU
X'20'
> ...
> TM FLAGS,F_FUBAR
> JO TOTALLY_HOSED
>
> Furthermore, you can
assign a "length" to each bit, and use that as an
offset in the field, e.g:
>
> FLAGS DS XL4
> F_OPEN EQU X'80',0
> F_CLOSE EQU X'40',0
> F_FUBAR EQU X'02',3
> ...
>
TM FLAGS+L'F_FUBAR,F_FUBAR
>
> (apologies if the syntax is not precise
... I'm doing this from memory at home).
>
> As to Charles'
comment about using EQU as a branch target, I'm a little
bit less comfortable. If — by chance or accident —
there happens to be code before the EQU that knocks the
location off a halfword boundary, this could spell
trouble. E.g:
>
>
LA 7,ITS_ON
>
TM BYTE,BIT
>
BCR X'01',7
>
...
> other
instructions
> HI_MOM DC
C'Hello'
> ITS_ON EQU *
>
> Since the constant
"Hello" is 5 bytes long, this knocks the label
ITS_ON onto an odd boundary. If the branch had been directly
to the location (as opposed to BCR), HLASM would have
flagged an error. But in this case, the error may go
undetected until execution — at which point the hardware
will slap you with a PIC-0006 (PIC-0006).
Gary Weinhold
Senior
Application Architect
DATAKINETICS | Data Performance &
Optimization
Phone
+1.613.523.5500 x216
Email: weinh...@dkl.com
Visit us online at www.DKL.com
E-mail Notification: The
information contained in this email and any attachments is
confidential and may be subject to copyright or other
intellectual property protection. If you are not the
intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us
by reply mail or telephone and delete the original message
from your mail system.
