On 2018-08-06, at 16:55:00, Seymour J Metz wrote:
> Why try totally irrelevant code? ...
>
Somehow, I'm reminded:
https://xkcd.com/325/
... not what you asked for!
-- gil
n column 1, not in
the operand.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Robin Vowels
Sent: Monday, August 6, 2018 6:47 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EQU * considered har
On 2018-08-06, at 16:47:33, Robin Vowels wrote:
>
>> True, but irrelevant. Adding a B or F to a label reference in any other
>> assembler
>> doesn't have the same semantics. E.g., this doesn't work:
>
>>TMoperand,mask
>>BOFOOF
>>XRR0,R0
>> FOO AR
rv.uga.edu
Subject: Re: EQU * considered harmful
From: "Seymour J Metz"
Sent: Monday, August 06, 2018 5:52 AM
Technical Assembly Systemm (TASS) on the 650 had something called a program
point.
A program point was a one digit label, and the references to program points
were suffixed
From: IBM Mainframe Assembler List on behalf
of Robin Vowels
Sent: Sunday, August 5, 2018 9:21 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EQU * considered harmful
From: "Seymour J Metz"
Sent: Monday, August 06, 2018 5:52 AM
> Technical Ass
Knuth's scheme wasn't relative bytes, nor instructions, nor even source
code lines. It was an actual coded label with very local scope. No
hazard from inserting instructions.
Yes, exactly. That's what made it maintainable and not error-prone.
So nothing fancy, it was something like this:
From: "Seymour J Metz"
Sent: Monday, August 06, 2018 6:05 AM
We were all very conscious of "economy in all things programming" in those
days.
We? I've been programming since 1960, and I was never concerned with how much space the source code
took.
Right, that was unimportant. And at 200
From: "Seymour J Metz"
Sent: Monday, August 06, 2018 5:52 AM
Technical Assembly Systemm (TASS) on the 650 had something called a program
point.
A program point was a one digit label, and the references to program points
were suffixed
with B for backwards and F for forward. It is perhaps the
ist on behalf
of Peter Relson
Sent: Friday, August 3, 2018 7:46 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EQU * considered harmful
> B *+12
I have no evidence one way or the other, but I wonder whether the writers
of the "old" macros that used this style did so be
: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EQU * considered harmful
We were all very conscious of "economy in all things programming" in those
days. A label occupied a physical punched card or 80 bytes of precious DASD
space. Medium-sized (by the standards of those days) assemblies took
: Saturday, August 4, 2018 10:23 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EQU * considered harmful
>"This isn't a 'real' branch-that is, we aren't going very far..."
Donald Knuth's assembler, which we had available in college in the 70's,
had the concept of a "relati
: Friday, August 3, 2018 1:05 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EQU * considered harmful
Those were just made up instructions, not real code.
The point was that I was taught that when you branch around multiple
instructions, to make it clear to someone else, you can:
1) Write
Knuth's ASSEMLER is called MIXAL, because it was designed for the
hypothetical machine MIX.
There are some tutorials on the web for MIX and MIXAL.
The local symbols of MIXAL are described here:
http://www.gnu.org/software/mdk/manual/html_node/Local-symbols.html#Local-symbols
Kind regards
@LISTSERV.UGA.EDU
Subject: Re: EQU * considered harmful
On 2018-08-04, at 09:21:14, Charles Mills wrote:
>
> The HLASM team's dance card is already pretty full but you can certainly
> picture something like that in HLASM:
>
> J *+3I
>
> Meaning "here + 3 instructions.&qu
On 2018-08-04, at 09:21:14, Charles Mills wrote:
>
> The HLASM team's dance card is already pretty full but you can certainly
> picture something like that in HLASM:
>
> J *+3I
>
> Meaning "here + 3 instructions." 'I' is perhaps not the best indicator
> because it is easily confused with a
On 2018-08-04, at 08:23:00, Peter Relson wrote:
>> "This isn't a 'real' branch-that is, we aren't going very far..."
>
> Donald Knuth's assembler, which we had available in college in the 70's,
> had the concept of a "relative label".
> I can't remember if there was one name pattern for
hought inserts or deletes an instruction?"
problem.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Peter Relson
Sent: Saturday, August 4, 2018 7:23 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU * considered
>"This isn't a 'real' branch-that is, we aren't going very far..."
Donald Knuth's assembler, which we had available in college in the 70's,
had the concept of a "relative label".
I can't remember if there was one name pattern for "forward" and one for
"backward" or whether you couldn't use it
From: "Tom Marchant" <00a69b48f3bb-dmarc-requ...@listserv.uga.edu>
Sent: Saturday, August 04, 2018 3:44 AM
On Fri, 3 Aug 2018 12:03:02 -0400, Tony Thigpen wrote:
I was taught that to make it easy to read, do the following:
BL *+4+2
LR R1,R2
How about
THIS BL
From: "Mark Hammack"
Sent: Saturday, August 04, 2018 2:16 AM
In 1985 (first MF assembler gig, I had been doing PC programming before
that), we were using Assembler H on MVS/XA (as I recall). Our shop
standard was to use EQU * for labels
Poor pprogramming practice.
and ALWAYS code a a
From: "Tony Thigpen"
Sent: Saturday, August 04, 2018 2:03 AM
I was taught that to make it easy to read, do the following:
BL *+4+2
LR R1,R2
or
BL *+4+2+4
LR R1,R2
LA R3,0(,r1)
It may not look right in your email, but the branched around
instructions
From: "Charles Mills"
Sent: Saturday, August 04, 2018 1:12 AM
We were all very conscious of "economy in all things programming" in those
days. A label occupied a physical punched card or 80 bytes of precious DASD
space.
DASD space was not precious. Nor were cards (cheap as chips).
And the
From: "Hobart Spitz"
Sent: Friday, August 03, 2018 8:59 AM
I think we are missing some points here. If you put a label on an
instruction, the symbol is defined with the correct length (2, 4, or 6),
and a type of C'I'.
Why? It's an instruction,. It is the subject of a branch,
or a
On Fri, 3 Aug 2018 12:03:02 -0400, Tony Thigpen wrote:
>I was taught that to make it easy to read, do the following:
> BL *+4+2
>LR R1,R2
How about
THIS BL *+L'THIS+L'NEXT
NEXTLR R1,R2
--
Tom Marchant
e?use_case=viewRfe_ID=85682
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Paul Gilmartin
Sent: Thursday, August 2, 2018 12:26 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: [EXTERNAL] Re: EQU * considered harmful
On 2018-08-02, at 12:03:12, Phil Smith III wrote:
>
&
I mean, if you would code a macro and use
ERROR NOTLOW, 30303
It would be a different discussion. I think dome 4+4+2+4 keeps me busy way
longer.
Rob
On Fri, 3 Aug 2018 at 19:05, Tony Thigpen wrote:
> Those were just made up instructions, not real code.
>
> The point was that I was taught
Those were just made up instructions, not real code.
The point was that I was taught that when you branch around multiple
instructions, to make it clear to someone else, you can:
1) Write the *+ information so that it was obvious that there were
multiple instructions and the length you
lf Of Mark Hammack
Sent: Friday, August 3, 2018 9:17 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU * considered harmful
In 1985 (first MF assembler gig, I had been doing PC programming before
that), we were using Assembler H on MVS/XA (as I recall). Our shop
standard was to use EQU *
In 1985 (first MF assembler gig, I had been doing PC programming before
that), we were using Assembler H on MVS/XA (as I recall). Our shop
standard was to use EQU * for labels and ALWAYS code a a label on a branch
in open code, even if it was just skipping a single instruction. Macros
were
I’m afraid those sequences only make sense when you wrote them, not much
later. I inherited similar attempts to code the length of data. Just don’t.
On Fri, 3 Aug 2018 at 18:03, Tony Thigpen wrote:
> I was taught that to make it easy to read, do the following:
>BL *+4+2
> LR
I was taught that to make it easy to read, do the following:
BL *+4+2
LR R1,R2
or
BL *+4+2+4
LR R1,R2
LA R3,0(,r1)
It may not look right in your email, but the branched around
instructions are indented one extra character.
Tony Thigpen
Phil Smith III
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Phil Smith III
Sent: Friday, August 3, 2018 7:40 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU * considered harmful
Peter Relson wrote:
>I have no evidence one way or the other, but I won
Peter Relson wrote:
>I have no evidence one way or the other, but I wonder whether the writers
>of the "old" macros that used this style did so because they liked it (I
>think we can all agree that we now hate it), or because they wanted to
>avoid clutter of the listing or clutter of the
> B *+12
I have no evidence one way or the other, but I wonder whether the writers
of the "old" macros that used this style did so because they liked it (I
think we can all agree that we now hate it), or because they wanted to
avoid clutter of the listing or clutter of the XREF due
On Fri, 3 Aug 2018 at 03:32, Phil Smith III wrote:
> Hobart Spitz wrote:
>
> >can't endorse either DS 0H or EQU *; use structured macros instead.
>
> Why "can't endorse"? I'm not getting your point.
>
I'm with Hobart there. I have *never* had the problem that I was coding a
branch to a data
Hobart Spitz wrote:
>I think we are missing some points here. If you put a label on an
>instruction, the symbol is defined with the correct length (2, 4, or 6),
>and a type of C'I'. Unless and until there is a MACRO that does this, I
>can't endorse either DS 0H or EQU *; use structured
I think we are missing some points here. If you put a label on an
instruction, the symbol is defined with the correct length (2, 4, or 6),
and a type of C'I'. Unless and until there is a MACRO that does this, I
can't endorse either DS 0H or EQU *; use structured macros instead.
OREXXMan
JCL is
On 08/02/2018 04:09 PM, Paul Gilmartin wrote:
On 2018-08-02, at 14:00:37, Steve Thompson wrote:
I haven't touched a Univac since 1979. So I forgot a few things. But still, the
36 bit words made it a pain for communicating with a DEC. I was asked how to
get them to talk to each other... It
On 2018-08-02, at 14:00:37, Steve Thompson wrote:
>
> I haven't touched a Univac since 1979. So I forgot a few things. But still,
> the 36 bit words made it a pain for communicating with a DEC. I was asked how
> to get them to talk to each other... It was interesting -- thankfully I kept
>
Wednesday, August 1, 2018 8:24 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EQU * considered harmful
IBM is committed to this (instructions take an even number of
bytes) because the machine is architected that way (long story
that is anchored back in the S/360 architecture). Be glad we
aren't do
On 2018-08-02, at 12:03:12, Phil Smith III wrote:
>
> Heh. "Wander". You're not declaring anything: when I say "EQU *" I am
> thinking, "I don't know or care about alignment, I mean Right Damned Here.
> Maybe it's halfword-aligned, maybe not. I don't care. To me, that's different
> from DC .
Steve Smith continued this great discussion:
>What's "wrong" with it is that EQU * is merely a gratuitous way to hide
>your intention on any alignment requirement. Does EQU * give you any
>advantage over DS0X?
>The statement earlier about "stick a pin right here" is just specious. Is
@listserv.uga.edu
Subject: Re: EQU * considered harmful
Ref: Your note of Thu, 2 Aug 2018 16:36:56 +
The Nominal Value is normally required, but an exception is
documented a few lines down:
Rules for DC operands
1. The type subfield and the nominal value must always be
specified unless
ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EQU * considered harmful
On 2018-08-02, at 10:10:33, Seymour J Metz wrote:
> 1. I don't have an obligation to back it up. You are free to remain ignorant.
>
Sometimes an example helps not only the person to whom you are responding
but als
> behalf of Jonathan Scott
> Sent: Thursday, August 2, 2018 12:26 PM
> To: ASSEMBLER-LIST@listserv.uga.edu
> Subject: Re: EQU * considered harmful
>
> Plain DC 0H has been supported by HLASM since at least 1.3,
> about 20 years ago.
>
> Jonathan Scott, HLASM
> IBM Hursley, UK
On 2018-08-02, at 10:10:33, Seymour J Metz wrote:
> 1. I don't have an obligation to back it up. You are free to remain ignorant.
>
Sometimes an example helps not only the person to whom you are responding
but also other readers of the list.
> 2. RYFM
>
Cite. Publication and section number.
c-requ...@listserv.uga.edu>
Sent: Wednesday, August 1, 2018 7:05 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EQU * considered harmful
On 2018-08-01, at 16:23:25, Gord Tomlin wrote:
>
> Here's one to rail about: branching to a hard coded offset from the current
> location, e.g.,
&g
@listserv.uga.edu
Subject: Re: EQU * considered harmful
Plain DC 0H has been supported by HLASM since at least 1.3,
about 20 years ago.
Jonathan Scott, HLASM
IBM Hursley, UK
t of line?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Steve Thompson
Sent: Wednesday, August 1, 2018 8:24 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EQU * considered harmful
IBM is
Plain DC 0H has been supported by HLASM since at least 1.3,
about 20 years ago.
Jonathan Scott, HLASM
IBM Hursley, UK
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EQU * considered harmful
If you're going to directly dispute what I said, then you have an
obligation to back it up.
sas
On Thu, Aug 2, 2018 at 12:03 PM, Seymour J Metz wrote:
> > In any case, plain DC 0H (or any other unit) has been sup
What's "wrong" with it is that EQU * is merely a gratuitous way to hide
your intention on any alignment requirement. Does EQU * give you any
advantage over DS0X?
The statement earlier about "stick a pin right here" is just specious. Is
there some confusion that regular DS/DC symbols might
Or SOMENEXT EQU *, the next entry in some sequential table?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Phil Smith III
Sent: Thursday, August 2, 2018 9:03 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU
smetz3
From: IBM Mainframe Assembler List on behalf
of Steve Smith
Sent: Thursday, August 2, 2018 11:06 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EQU * considered harmful
Yes, DS "skips" bytes for alignment, and those skipped aren't guarantee
Steve Smith wrote, in part:
>Note that I don't think EQU * should be used in data areas either, where it
>is potentially more dangerous. This is the kind of error that motivated
>me to write this up.
I'm sure it can be; what's wrong with this:
SOME DSECT ,
SOMEADSF
SOMEB
is guaranteed (if that is the right word) to contain 'XBZ'.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Smith
Sent: Thursday, August 2, 2018 8:07 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU * considered
Yes, DS "skips" bytes for alignment, and those skipped aren't guaranteed to
be anything. But why would you care?
In any case, plain DC 0H (or any other unit) has been supported for a long
time, if not from the beginning of HLASM. I don't care what's in padding,
but DC does pad with 00 text, and
Charles Mills wrote:
>Ooh. Don't know if I like that or if the "WTF?" factor for *+8 as a "label"
>is too great.
Well, the WTF factor is sort of the point: "Pay attention, there be dragons
here". But that was essentially the argument I was given against doing it:
"Don't need more dragons"!
M
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU * considered harmful
Charles Mills wrote:
>I have a house rule to use J (not B!) *+n only to jump over a single
instruction, never more than one. Yeah, it may be a problem waiting to
happen, especially now with machine instruction length a little
Charles Mills wrote:
>I have a house rule to use J (not B!) *+n only to jump over a single
>instruction, never more than one. Yeah, it may be a problem waiting to happen,
>especially now with machine instruction length a little less intuitive (change
>A to AG and there goes your J *+8). What I
On 2018-08-01 18:49, Charles Mills wrote:
See you in STL?
'fraid not. Nose to the grindstone.
--
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/
ssage-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Gord Tomlin
Sent: Wednesday, August 1, 2018 3:23 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU * considered harmful
On 2018-08-01 16:41, Charles Mills wrote:
"Avoid instructions
frame Assembler List On Behalf
Of Gary Weinhold
Sent: Wednesday, August 1, 2018 2:40 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU * considered harmful
To avoid the problem Dan illustrates but retain the advantages Charles cites
of not labeling specific instructions, we use
label DS
On 2018-08-01, at 16:23:25, Gord Tomlin wrote:
>
> Here's one to rail about: branching to a hard coded offset from the current
> location, e.g.,
> B *+12
>
> This is a tire fire waiting to happen.
>
Better-featured assemblers provide symbols with local scope for this purpose.
is
.
See you in STL?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Gord Tomlin
Sent: Wednesday, August 1, 2018 3:23 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU * considered harmful
On 2018-08-01 16:41, Cha
On 2018-08-01 16:41, Charles Mills wrote:
"Avoid instructions (executable code) and operand data (working storage or
stack storage) in the same cache lines; which
can be costly due to moving cache lines between the separated (split) local caches
(instruction/data L1/L2)"
-- C. Kevin Shum,
Steve Smith wrote:
>A couple of clarifications:
>1a. I did not say EQU was harmful. It's actually invaluable.
>1b. I did not say '*' was harmful. It's actually invaluable.
>2. Show me an EQU * that couldn't easily be replaced by DC 0X (or 0H, or
>0F, or 0D, or 0LQ).
>If you
Typography note... maybe I should have been clearer about 'EQU *' being the
assembler syntax, and not a misleading reference to a non-existent footnote.
sas
A couple of clarifications:
1a. I did not say EQU was harmful. It's actually invaluable.
1b. I did not say '*' was harmful. It's actually invaluable.
2. Show me an EQU * that couldn't easily be replaced by DC 0X (or 0H, or
0F, or 0D, or 0LQ).
If you personally prefer the "look" of EQU * over
z Systems Microprocessor
Development (March 2016)
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Keith Moe
Sent: Wednesday, August 1, 2018 1:27 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU * considered harmful
I
tware, Inc.
On Wed, 8/1/18, Charles Mills wrote:
Subject: Re: EQU * considered harmful
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Date: Wednesday, August 1, 2018, 1:05 PM
Well, one could argue that
"DS" implies a variable, not instructions, and is
therefore inappr
I you have trouble pounding in nails with a screwdriver and turning screws with
a hammer, it's not the tools that are defective. EQU is important to
understandable programming. I could equally well make a case that LA is bad
because someone had misused it.
--
Shmuel (Seymour J.) Metz
e warning.
Keith Moe
BMC Software, Inc.
On Wed, 8/1/18, Gary Weinhold 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
oe
BMC Software, Inc.
On Wed, 8/1/18, Gary Weinhold 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 i
On 2018-08-01, at 12:23:20, Dan Greiner wrote:
>
> 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
that
is either variable length or liable to change in length.
richard
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Gary Weinhold
Sent: Wednesday, August 01, 2018 2:40 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU
Dan,
While I disagree with the original poster, you are not talking about the
same thing he is.
He is specifically talking only about 'EQU *'. You have expanded that to
any 'EQU' usage.
Tony Thigpen
Dan Greiner wrote on 08/01/2018 02:23 PM:
I too disagree (rather strongly).
As an
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
I too disagree (rather strongly).
As an example, consider where EQU is used to give names to bits of a field in
memory.
FLAGSDSX
F_OPEN EQU X'80'
F_CLOSE EQU X'40'
F_FUBAR EQU X'20'
...
TMFLAGS,F_FUBAR
JOTOTALLY_HOSED
Furthermore, you can assign a
I don't agree. I use label EQU * in a stream of executable instructions. I
think it is clearer that the label represents a point in the logic flow, not a
particular instruction, especially in situations like
TM some_condition
JNO Not_Whatever
Instructions dealing with the
I have seen IBM DSECTS that map variable-length records, and the start of the
variable part states "EQU *"
Pieter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Smith
Sent: 01 August 2018 18:34
To:
I very often use it to define location and length of a composite set of
variables. Your END idea would not help me. And don’t we do plain constants
like hash table size? Don’t think length is always known early enough. And
bits in a flag byte?
Rob
On Wed, 1 Aug 2018 at 18:34, Steve Smith wrote:
82 matches
Mail list logo
