subject:"Re\: EQU \* considered harmful"

>When labels were limited to 8 characters 

That was an improvement over the 5 characters that we had on the 650 or the 6 
characters that we had on the 7090.


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


From: IBM Mainframe Assembler List  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 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 to the extra
labels (thus increasing the size of the listing at a time when that
translated into a real cost of printing), or whether maybe assembler F
(that's the earliest IBM assembler I ever worked with) had limits that
they were worried about running aground upon, or ...

I wonder if it had to do with to label uniqueness. When labels were
limited to 8 characters (as they were at that time), even with ,
maybe there was some concern about interfering with a user-created label.
Nowadays, macroname_ is something we probably wouldn't mind
creating as a label.

Peter Relson
z/OS Core Technology Design

Re: EQU * considered harmful

>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. The important things were how quickly the code ran 
and how easy it was to maintain. There's economy and there's false economy.

>A label would consume two lines of printout,

Not unless you had it on an extraneous DS0H, EQU   *, or equivalent, and 
even then an extra line on the listing was no big deal.

BTW, when I started 8-character labels would have sounded like Heaven; I was 
used to 5-character labels and even the big powerful 7090 only had 6-character 
labels.

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

From: IBM Mainframe Assembler List  on behalf 
of Charles Mills 
Sent: Friday, August 3, 2018 11:12 AM
To: 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 minutes
and produced large paper listings. A label would consume two lines of
printout, one for the label and one for the xref (and one more if the macro
were local in the source file). I can easily envision someone saying "why
did you code that label??? You didn't need to do that! You could have just
coded *+12"

Charles

-Original Message-
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 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 to the extra

>labels (thus increasing the size of the listing at a time when that

>translated into a real cost of printing), or whether maybe assembler F

>(that's the earliest IBM assembler I ever worked with) had limits that

>they were worried about running aground upon, or ...

>I wonder if it had to do with to label uniqueness. When labels were

>limited to 8 characters (as they were at that time), even with ,

>maybe there was some concern about interfering with a user-created label.

>Nowadays, macroname_ is something we probably wouldn't mind

>creating as a label.

All good points. I think there was an element of keeping things cleaner/not
having to scavenge for label uniqueness with 8-character labels.

I don't remember who taught me the technique, though it must have been at
UofW in the early 80s. I internalized it as "This isn't a 'real' branch-that
is, we aren't going very far, just skipping a single instruction". And I
would never, ever, ever consider doing it for more than one instruction.

Re: EQU * considered harmful

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 
only thing on the 650 that I miss.

Somewhat more general was the QUAL statement in IBMAP, which designated a 
section of code in which labels were implicitly qualified with the section name.


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


From: IBM Mainframe Assembler List  on behalf 
of Peter Relson 
Sent: 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 "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 for "backward". It avoided
unnecessarily unreadable label names, and avoided the uniqueness problem.
And when used properly (i.e., well within a "screen" amout) it was
perfectly clear.

The label name was like "1R" for "first one ahead, relative" or perhaps it
was "find the first 1R label ahead", for example
J 1R

When used appropriately (as a substitue for all of these *+small_number
types of cases) it avoided the maintainability problems of having to know
how long everything was.

By the way, I still remember being amazed at a demonstration of producing
"N factorial" using IBM/360 assembler macro language (at least for small
enough numbers).

Peter Relson
z/OS Core Technology Design

Re: EQU * considered harmful

That's better than adding the lengths up yourself, but still not as robust as 
using labels, either explicit or macro generated.

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

From: IBM Mainframe Assembler List  on behalf 
of Tony Thigpen 
Sent: 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 the *+ information so that it was obvious that there were
multiple instructions and the length you expected them to be, and,
2) Indent the instructions being branched around so that, again, it is
obvious that something needed to be looked at if the code was modified.

Personally, adding an extra label when branching around one, or two
instructions just makes the program more cluttered.

One place I used this a lot is when handling errors.
 BL *+4+4+4
  L R15,ERRNO_30303
  B General_error_routine
 MVCX,Y
(Again, just typing some example code, not actual code.)

Of course, I also use GOTO in COBOL, so maybe I am just a non-standard
person.

Tony Thigpen

Rob van der Heij wrote on 08/03/2018 12:13 PM:
> 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  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 wrote on 08/03/2018 10:40 AM:
>>> Peter Relson wrote:
>>>
>>> I don't remember who taught me the technique, though it must have been
>> at UofW in the early 80s. I internalized it as "This isn't a 'real'
>> branch-that is, we aren't going very far, just skipping a single
>> instruction". And I would never, ever, ever consider doing it for more than
>> one instruction.
>>>
>>>
>>
>
>

Re: EQU * considered harmful

2018-08-05 Thread Bernd Oppolzer


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

Bernd


Am 04.08.2018 um 16:23 schrieb Peter Relson:

"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 for "backward". It avoided
unnecessarily unreadable label names, and avoided the uniqueness problem.
And when used properly (i.e., well within a "screen" amout) it was
perfectly clear.

The label name was like "1R" for "first one ahead, relative" or perhaps it
was "find the first 1R label ahead", for example
J 1R

When used appropriately (as a substitue for all of these *+small_number
types of cases) it avoided the maintainability problems of having to know
how long everything was.

By the way, I still remember being amazed at a demonstration of producing
"N factorial" using IBM/360 assembler macro language (at least for small
enough numbers).

Peter Relson
z/OS Core Technology Design

Re: EQU * considered harmful

2018-08-04 Thread Charles Mills

Okay. Not picturing it exactly but okay.

I like mine better  but don't like it very much.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Saturday, August 4, 2018 9:14 AM
To: ASSEMBLER-LIST@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." 'I' is perhaps not the best indicator
> because it is easily confused with a digit, although J *+n seldom ends in
a
> legitimate 1.
> 
> Yes, the assembler would have to do look-ahead. Yes, HLASM would have to
> impose some limits and caveats.
> 
> I'm not crazy about it. It solves the "what if the instruction length
> changes, such as from A to AG?" problem, but not the "what if someone
> hastily and with inadequate thought inserts or deletes an instruction?"
> problem.
>  
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.

Re: EQU * considered harmful

2018-08-04 Thread Paul Gilmartin

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 digit, although J *+n seldom ends in a
> legitimate 1.
> 
> Yes, the assembler would have to do look-ahead. Yes, HLASM would have to
> impose some limits and caveats.
> 
> I'm not crazy about it. It solves the "what if the instruction length
> changes, such as from A to AG?" problem, but not the "what if someone
> hastily and with inadequate thought inserts or deletes an instruction?"
> problem.
>  
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.


> -Original Message-
> From: Peter Relson
> Sent: Saturday, August 4, 2018 7:23 AM
> 
>> "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 for "backward". It avoided  
>   
(IIRC, the former.)

> unnecessarily unreadable label names, and avoided the uniqueness problem. 
> And when used properly (i.e., well within a "screen" amout) it was 
> perfectly clear.
>  
And hardly needed cross-reference.

-- gil

Re: EQU * considered harmful

2018-08-04 Thread Paul Gilmartin

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 "forward" and one for 
> "backward" or whether you couldn't use it for "backward". It avoided 
> unnecessarily unreadable label names, and avoided the uniqueness problem. 
> And when used properly (i.e., well within a "screen" amout) it was 
> perfectly clear.
>  
RFE?

-- gil

Re: EQU * considered harmful

2018-08-04 Thread Charles Mills

Interesting.

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 digit, although J *+n seldom ends in a
legitimate 1.

Yes, the assembler would have to do look-ahead. Yes, HLASM would have to
impose some limits and caveats.

I'm not crazy about it. It solves the "what if the instruction length
changes, such as from A to AG?" problem, but not the "what if someone
hastily and with inadequate thought 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 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 "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 for "backward". It avoided 
unnecessarily unreadable label names, and avoided the uniqueness problem. 
And when used properly (i.e., well within a "screen" amout) it was 
perfectly clear.

The label name was like "1R" for "first one ahead, relative" or perhaps it 
was "find the first 1R label ahead", for example 
J 1R

When used appropriately (as a substitue for all of these *+small_number 
types of cases) it avoided the maintainability problems of having to know 
how long everything was.

Re: EQU * considered harmful

2018-08-04 Thread Peter Relson

>"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 for "backward". It avoided 
unnecessarily unreadable label names, and avoided the uniqueness problem. 
And when used properly (i.e., well within a "screen" amout) it was 
perfectly clear.

The label name was like "1R" for "first one ahead, relative" or perhaps it 
was "find the first 1R label ahead", for example 
J 1R

When used appropriately (as a substitue for all of these *+small_number 
types of cases) it avoided the maintainability problems of having to know 
how long everything was.

By the way, I still remember being amazed at a demonstration of producing 
"N factorial" using IBM/360 assembler macro language (at least for small 
enough numbers). 

Peter Relson
z/OS Core Technology Design

Re: EQU * considered harmful


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   *+L'THIS+L'NEXT
NEXTLR  R1,R2






remember KISS?

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: EQU * considered harmful


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 label on a branch
in open code, even if it was just skipping a single instruction.  Macros
were another matter (and we had a lot).

Personally, I've only had a couple of instances since 1982 where EQU *
caused an issue that DS 0H wouldn't have...and the assembler caught those.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: EQU * considered harmful


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 are indented one extra character.


One instruction might be OK, but more than one was asking for trouble.
Better to use a label.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: EQU * considered harmful


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 LP was fairly fast.


Medium-sized (by the standards of those days) assemblies took minutes
and produced large paper listings.


Naturally, that's assembler.


A label would consume two lines of
printout, one for the label and one for the xref (and one more if the macro
were local in the source file). I can easily envision someone saying "why
did you code that label??? You didn't need to do that! You could have just
coded *+12"


There was none of that, even in earlier days, when an assembly took
up to 15 minutes.

One extra card at 200 cpm was nothing.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: EQU * considered harmful


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 reference.


 Unless and until there is a MACRO that does this, I
can't endorse either DS 0H or EQU *; use structured macros instead.



DS 0H has always been preferred.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: EQU * considered harmful

2018-08-03 Thread Tom Marchant

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

Re: [EXTERNAL] Re: EQU * considered harmful

2018-08-03 Thread Swarbrick, Frank

"Why isn't the length attribute of a DSECT its actual length?"
I don't have a good answer, but I do have a related RFE you can vote for.  For 
all the good it will do, as it's never received a response from IBM as far as I 
can tell...
https://www.ibm.com/developerworks/rfe/execute?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:
>
> 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 . But I'd be the first to admit that it's subtle, and might 
> be just me.
>
Sounds like a suitable thing to indicate the end of a control block.  Useful to 
compute its lenth, and what else?  Perhaps the END operand of a dependent USING?

What should its type be?

What should the type of the length be?

Why isn't the length attribute of a DSECT its actual length?

Etc.?

-- gil

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

Re: EQU * considered harmful

2018-08-03 Thread Rob van der Heij

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 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 expected them to be, and,
> 2) Indent the instructions being branched around so that, again, it is
> obvious that something needed to be looked at if the code was modified.
>
> Personally, adding an extra label when branching around one, or two
> instructions just makes the program more cluttered.
>
> One place I used this a lot is when handling errors.
>  BL *+4+4+4
>   L R15,ERRNO_30303
>   B General_error_routine
>  MVCX,Y
> (Again, just typing some example code, not actual code.)
>
> Of course, I also use GOTO in COBOL, so maybe I am just a non-standard
> person.
>
> Tony Thigpen
>
> Rob van der Heij wrote on 08/03/2018 12:13 PM:
> > 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  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 wrote on 08/03/2018 10:40 AM:
> >>> Peter Relson wrote:
> >>>
> >>> I don't remember who taught me the technique, though it must have been
> >> at UofW in the early 80s. I internalized it as "This isn't a 'real'
> >> branch-that is, we aren't going very far, just skipping a single
> >> instruction". And I would never, ever, ever consider doing it for more
> than
> >> one instruction.
> >>>
> >>>
> >>
> >
> >
>

Re: EQU * considered harmful

2018-08-03 Thread Tony Thigpen


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 expected them to be, and,
2) Indent the instructions being branched around so that, again, it is 
obvious that something needed to be looked at if the code was modified.


Personally, adding an extra label when branching around one, or two 
instructions just makes the program more cluttered.


One place I used this a lot is when handling errors.
BL *+4+4+4
 L R15,ERRNO_30303
 B General_error_routine
MVCX,Y
(Again, just typing some example code, not actual code.)

Of course, I also use GOTO in COBOL, so maybe I am just a non-standard 
person.


Tony Thigpen

Rob van der Heij wrote on 08/03/2018 12:13 PM:

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  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 wrote on 08/03/2018 10:40 AM:

Peter Relson wrote:

I don't remember who taught me the technique, though it must have been

at UofW in the early 80s. I internalized it as "This isn't a 'real'
branch-that is, we aren't going very far, just skipping a single
instruction". And I would never, ever, ever consider doing it for more than
one instruction.

Re: EQU * considered harmful

2018-08-03 Thread Charles Mills

Right! Of all of the problematic coding techniques in the world, EQU * in 
instructions is very low on the list IMHO. In order to have an odd 
(non-halfword) instruction label address really bite you, you would need to 
combine EQU * with two other questionable practices: interleaving code and data 
(to screw up the alignment), and branching "indirectly" to the address in 
question, because a direct branch or jump would give you a simple assembly 
error.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf 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 * 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 another matter (and we had a lot).

Personally, I've only had a couple of instances since 1982 where EQU *
caused an issue that DS 0H wouldn't have...and the assembler caught those.

Re: EQU * considered harmful

2018-08-03 Thread Mark Hammack

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 another matter (and we had a lot).

Personally, I've only had a couple of instances since 1982 where EQU *
caused an issue that DS 0H wouldn't have...and the assembler caught those.

*Mark*

On Fri, Aug 3, 2018 at 11:03 AM Tony Thigpen  wrote:

> 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 wrote on 08/03/2018 10:40 AM:
> > Peter Relson wrote:
> >
> > I don't remember who taught me the technique, though it must have been
> at UofW in the early 80s. I internalized it as "This isn't a 'real'
> branch-that is, we aren't going very far, just skipping a single
> instruction". And I would never, ever, ever consider doing it for more than
> one instruction.
> >
> >
>

Re: EQU * considered harmful

2018-08-03 Thread Rob van der Heij

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  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 wrote on 08/03/2018 10:40 AM:
> > Peter Relson wrote:
> >
> > I don't remember who taught me the technique, though it must have been
> at UofW in the early 80s. I internalized it as "This isn't a 'real'
> branch-that is, we aren't going very far, just skipping a single
> instruction". And I would never, ever, ever consider doing it for more than
> one instruction.
> >
> >
>

Re: EQU * considered harmful

2018-08-03 Thread Tony Thigpen


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 wrote on 08/03/2018 10:40 AM:

Peter Relson wrote:

I don't remember who taught me the technique, though it must have been at UofW in the 
early 80s. I internalized it as "This isn't a 'real' branch-that is, we aren't going 
very far, just skipping a single instruction". And I would never, ever, ever 
consider doing it for more than one instruction.

Re: EQU * considered harmful

2018-08-03 Thread Charles Mills

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 minutes
and produced large paper listings. A label would consume two lines of
printout, one for the label and one for the xref (and one more if the macro
were local in the source file). I can easily envision someone saying "why
did you code that label??? You didn't need to do that! You could have just
coded *+12"

Charles

-Original Message-
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 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 to the extra 

>labels (thus increasing the size of the listing at a time when that 

>translated into a real cost of printing), or whether maybe assembler F 

>(that's the earliest IBM assembler I ever worked with) had limits that 

>they were worried about running aground upon, or ...

>I wonder if it had to do with to label uniqueness. When labels were 

>limited to 8 characters (as they were at that time), even with , 

>maybe there was some concern about interfering with a user-created label. 

>Nowadays, macroname_ is something we probably wouldn't mind 

>creating as a label.

All good points. I think there was an element of keeping things cleaner/not
having to scavenge for label uniqueness with 8-character labels.

I don't remember who taught me the technique, though it must have been at
UofW in the early 80s. I internalized it as "This isn't a 'real' branch-that
is, we aren't going very far, just skipping a single instruction". And I
would never, ever, ever consider doing it for more than one instruction.

Re: EQU * considered harmful

2018-08-03 Thread Phil Smith III

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 XREF due to the extra 

>labels (thus increasing the size of the listing at a time when that 

>translated into a real cost of printing), or whether maybe assembler F 

>(that's the earliest IBM assembler I ever worked with) had limits that 

>they were worried about running aground upon, or ...

>I wonder if it had to do with to label uniqueness. When labels were 

>limited to 8 characters (as they were at that time), even with , 

>maybe there was some concern about interfering with a user-created label. 

>Nowadays, macroname_ is something we probably wouldn't mind 

>creating as a label.

All good points. I think there was an element of keeping things cleaner/not 
having to scavenge for label uniqueness with 8-character labels.

I don't remember who taught me the technique, though it must have been at UofW 
in the early 80s. I internalized it as "This isn't a 'real' branch-that is, we 
aren't going very far, just skipping a single instruction". And I would never, 
ever, ever consider doing it for more than one instruction.

Re: EQU * considered harmful

2018-08-03 Thread Peter Relson

> 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 to the extra 
labels (thus increasing the size of the listing at a time when that 
translated into a real cost of printing), or whether maybe assembler F 
(that's the earliest IBM assembler I ever worked with) had limits that 
they were worried about running aground upon, or ...

I wonder if it had to do with to label uniqueness. When labels were 
limited to 8 characters (as they were at that time), even with , 
maybe there was some concern about interfering with a user-created label. 
Nowadays, macroname_ is something we probably wouldn't mind 
creating as a label.

Peter Relson
z/OS Core Technology Design

Re: EQU * considered harmful

2018-08-03 Thread Rob van der Heij

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 field. With structured programming macros you don't have
to deal with that. I also like my COND macro that is a short-hand for a
conditional branch over a single instruction, like
  COND MINUS,LHI,R0,0

Cute. I never realized that it made type 'I' and that one could validate
that on the target of a branch. That looks like a sign that we were never
meant to code DS 0H for labels...

Rob

Re: EQU * considered harmful

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 macros instead.

 

Why "can't endorse"? I'm not getting your point.

Re: EQU * considered harmful

2018-08-02 Thread Hobart Spitz

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 the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Thu, Aug 2, 2018 at 4:29 PM Steve Thompson  wrote:

> 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 was interesting --
> thankfully I kept doing FORTRAN-77 and someone else built the interface box.
> >>
> > "If you don't have 36-bit words, you're not playing with a full DEC!"
> >
> > PDP-6, decsystem-10 and decsystem-20 had 36 bits.  Vax broke the mold.
> >
> > -- gil
> >
> It was NASA. They were using old equipment. I don't remember
> which DEC boxes they had, I was told that the I/O interface was
> 16bits wide.
>
> But, the Space Shuttle flew in spite of the fun we had writing
> the ground support software. -- Goddard Space Flight, Beltsville MD
>
> Regards,
> Steve Thompson
>

Re: EQU * considered harmful

2018-08-02 Thread Steve Thompson


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 was interesting -- thankfully I kept doing 
FORTRAN-77 and someone else built the interface box.
  

"If you don't have 36-bit words, you're not playing with a full DEC!"

PDP-6, decsystem-10 and decsystem-20 had 36 bits.  Vax broke the mold.

-- gil

It was NASA. They were using old equipment. I don't remember 
which DEC boxes they had, I was told that the I/O interface was 
16bits wide.


But, the Space Shuttle flew in spite of the fun we had writing 
the ground support software. -- Goddard Space Flight, Beltsville MD


Regards,
Steve Thompson

Re: EQU * considered harmful

2018-08-02 Thread Paul Gilmartin

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 
> doing FORTRAN-77 and someone else built the interface box.
>  
"If you don't have 36-bit words, you're not playing with a full DEC!"

PDP-6, decsystem-10 and decsystem-20 had 36 bits.  Vax broke the mold.

-- gil

Re: EQU * considered harmful

2018-08-02 Thread Steve Thompson


Shmuel:

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 doing FORTRAN-77 and someone 
else built the interface box.


I do not know about the IBM z machines today. I worked on ECL/TTL 
at Amdahl in Macrocode/MDF.


I've read stuff about the chip sets and sometimes at SHARE I get 
to talk with some people about the advances since the days I 
worked at Amdahl.


BAL -- Actually, I worked on an ASCII based machine that had NO 
Conditional assembly -- It was a Basic Assembly Language assembler.


That was for and with Digital Systems Corp (not DEC) in 
Walkersville MD -- Galaxy 5 machines. 20 bit addressing/word, no 
priv ops and no storage protection using. Competed favorably 
to/with IBM's S/3 15D machines. Used "Maytag" disk drives (2311 
type).


Regards,
Steve Thompson

On 08/02/2018 12:34 PM, Seymour J Metz wrote:

Be glad we aren't doing Univac


I wish that you had imitated the good parts


as I recall the U1100/x machines were word machines.

  Each instruction was 36bits long and there were 3
types of registers. General, FP, and Index IIRC.

Close; the same pool of accumulators was used for fixed and floating point. For 
many instructions it was possible to specify a 6-bit, 12-bit or 18-bit byte 
within the word.

The advantage of separating the accumulators from the index registers is that 
you get more of them. That doesn't matter for a machine like STAR-100 with an 
8-bit register number, but with a 4-bit number it's too easy to run out.


BAL/ALC since about 1976


ALC I believe. I seriously doubt that you were still running BPS in 1976.

BTW, what is the effect on the pipeline of an extraneous branch around the 
inline executed instruction, as compared to putting it out 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 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 doing Univac -- as I recall the U1100/x machines were word
machines. Each instruction was 36bits long and there were 3
types of registers. General, FP, and Index IIRC.

Answering another post here: The instruction and data being close
together such that they are in the same cache line causes what I
think is called a processor pipeline stall. With the G3 CMOS
chip-set that implemented I/D Bank cache, if an instruction were
to modify data within that cache line, the pipe would stall, the
system control code would have to force that cache line back into
C-Store, it would have to be fetched into the D-Bank cache, the
data fetch/update/write (whatever the instruction was) would be
done, the cache line would be flushed back to C-store and then
re-fetched back into the I Bank cache

That was the G3 level. I'm told that this was uncovered by SAS
because they were "generating" their code as they ran (I'm
thinking they were modifying their code) and so SAS programs ran
much more slowly than they had on the prior machine.

One observation I have as someone who has been programming in
BAL/ALC since about 1976. You guys wouldn't be able to program on
a S/360 with that level of assembler. Particularly if it were the
DOS Assembler.

The idea of EQU * in instructions made sense, and as others have
pointed out, didn't cause excessive TXT cards to be punched
(really had to pay attention to this on a S/360-20 -- oh the
inhumanity of it all with a SYSRES on tape -- My apologies to
Bones of Star Trek fame).

And structured ALC macros generate scads of unintelligible labels
(well, until you get used to the way it works). Be glad that we
can now use more than 8 characters for a label.

There are reasons for labels that one does not "branch" to,
whether by LA Rn,=(sss); BR Rn, or BALR, etc. And that is, if one
is using an interactive trace tool (such as TSO TEST -- I have
forgotten how to use it, XDC is so much better) one can specify
the PARM of TEST to the assembler and was it also LINKEDIT?

Anyway, you now have labeled points (on SYM cards) to set
breakpoints instead of offsets in the program.

Ya just gotta be old enough to have had to work that way back in
the day.

And Charles, sorry, this go around I will be in the office. I
just can't get free to go to SHARE. Maybe, possibly in spring 2019.

Regards,
Steve Thompson


On 08/01/2018 06:49 PM, Charles Mills wrote:

- IBM is pretty much committed to even-halfword instructions because Jump only 
jumps even halfwords.

- You want a confession? You know one reason why I got in the habit of not 
using

Re: EQU * considered harmful

2018-08-02 Thread Paul Gilmartin

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 . But I'd be the first to admit that it's subtle, and might 
> be just me.
>  
Sounds like a suitable thing to indicate the end of a control block.  Useful
to compute its lenth, and what else?  Perhaps the END operand of a dependent
USING?

What should its type be?

What should the type of the length be?

Why isn't the length attribute of a DSECT its actual length?

Etc.?

-- gil

Re: EQU * considered harmful

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

>there some confusion that regular DS/DC symbols might wander off somewhere?

 

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 
. But I'd be the first to admit that it's subtle, and might be just 
me.

 

>Not that I want to come off snarky, but IBM provides plenty of poor coding

>examples in various MACLIBs.  And, plenty of good ones too, but you have to

>use some judgement.

 

Heh, true dat. I've been spoiled, I think, coming originally from a VM 
background. The VM/XA (et ff.) code is beautifully written, structured, and 
documented; I'm consistently appalled at how grim the public z/OS code is, and 
can only assume that the OCO stuff is at least as bad. Of course VM had a big 
advantage, getting to rewrite from the ground up for XA.

 

...phsiii

Re: EQU * considered harmful

Yes, but the claim was that DC H was valid, not that DC 0H was valid.


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


From: IBM Mainframe Assembler List  on behalf 
of Jonathan Scott 
Sent: Thursday, August 2, 2018 12:43 PM
To: ASSEMBLER-LIST@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 the duplication factor is zero. If the
   duplication factor is zero, only the type must be specified.

> Is it RCF time? The reference manual shows Nominal Value as required.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Assembler List  on
> 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

Re: EQU * considered harmful

>Cite.  Publication and section number.

https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc264940/$file/asmr1023.pdf,
 but according to Jonathon Scott the manual is wrong.

Chapter 5, Assembler instruction statements, DC instruction on p 129, syntax 
chart on p. 131, Subfield 6: Nominal Value on p. 144.


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


From: IBM Mainframe Assembler List  on behalf 
of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Thursday, August 2, 2018 12:39 PM
To: 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 also other readers of the list.

> 2. RYFM
>
Cite.  Publication and section number.

-- gil

Re: EQU * considered harmful

2018-08-02 Thread Jonathan Scott

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 the duplication factor is zero. If the
   duplication factor is zero, only the type must be specified.

> Is it RCF time? The reference manual shows Nominal Value as required.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Assembler List  on
> 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

Re: EQU * considered harmful

2018-08-02 Thread Paul Gilmartin

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.

-- gil

Re: EQU * considered harmful

>Better-featured assemblers provide symbols with local scope for this purpose.

QUAL in IBMAP

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

From: IBM Mainframe Assembler List  on behalf 
of Paul Gilmartin <0014e0e4a59b-dmarc-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.,
> B *+12
>
> This is a tire fire waiting to happen.
>
Better-featured assemblers provide symbols with local scope for this purpose.

 is a boon here.  How many "B *+12" in SYS1.MACLIB ought to be replaced
with   But this clutters the cross-reference listing.

Long ago I worked with a simple Pascal compiler.  It didn't generate assembler
code, but branches to hard-coded offsets were endemic, and caused "tire fire"
when I changed the code generation.  Finally, I took the effort to ferret out
every one to defer calculating the offset and backfill from the target.  Mostly
piggybacked on existing logic for resolving GOTO displacements.

-- gil

Re: EQU * considered harmful

Is it RCF time? The reference manual shows Nominal Value as required.


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


From: IBM Mainframe Assembler List  on 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

Re: EQU * considered harmful

>Be glad we aren't doing Univac

I wish that you had imitated the good parts

>as I recall the U1100/x machines were word machines.
 Each instruction was 36bits long and there were 3 
types of registers. General, FP, and Index IIRC.

Close; the same pool of accumulators was used for fixed and floating point. For 
many instructions it was possible to specify a 6-bit, 12-bit or 18-bit byte 
within the word.

The advantage of separating the accumulators from the index registers is that 
you get more of them. That doesn't matter for a machine like STAR-100 with an 
8-bit register number, but with a 4-bit number it's too easy to run out.

>BAL/ALC since about 1976

ALC I believe. I seriously doubt that you were still running BPS in 1976.

BTW, what is the effect on the pipeline of an extraneous branch around the 
inline executed instruction, as compared to putting it out 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 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 doing Univac -- as I recall the U1100/x machines were word
machines. Each instruction was 36bits long and there were 3
types of registers. General, FP, and Index IIRC.

Answering another post here: The instruction and data being close
together such that they are in the same cache line causes what I
think is called a processor pipeline stall. With the G3 CMOS
chip-set that implemented I/D Bank cache, if an instruction were
to modify data within that cache line, the pipe would stall, the
system control code would have to force that cache line back into
C-Store, it would have to be fetched into the D-Bank cache, the
data fetch/update/write (whatever the instruction was) would be
done, the cache line would be flushed back to C-store and then
re-fetched back into the I Bank cache

That was the G3 level. I'm told that this was uncovered by SAS
because they were "generating" their code as they ran (I'm
thinking they were modifying their code) and so SAS programs ran
much more slowly than they had on the prior machine.

One observation I have as someone who has been programming in
BAL/ALC since about 1976. You guys wouldn't be able to program on
a S/360 with that level of assembler. Particularly if it were the
DOS Assembler.

The idea of EQU * in instructions made sense, and as others have
pointed out, didn't cause excessive TXT cards to be punched
(really had to pay attention to this on a S/360-20 -- oh the
inhumanity of it all with a SYSRES on tape -- My apologies to
Bones of Star Trek fame).

And structured ALC macros generate scads of unintelligible labels
(well, until you get used to the way it works). Be glad that we
can now use more than 8 characters for a label.

There are reasons for labels that one does not "branch" to,
whether by LA Rn,=(sss); BR Rn, or BALR, etc. And that is, if one
is using an interactive trace tool (such as TSO TEST -- I have
forgotten how to use it, XDC is so much better) one can specify
the PARM of TEST to the assembler and was it also LINKEDIT?

Anyway, you now have labeled points (on SYM cards) to set
breakpoints instead of offsets in the program.

Ya just gotta be old enough to have had to work that way back in
the day.

And Charles, sorry, this go around I will be in the office. I
just can't get free to go to SHARE. Maybe, possibly in spring 2019.

Regards,
Steve Thompson

On 08/01/2018 06:49 PM, Charles Mills wrote:
> - IBM is pretty much committed to even-halfword instructions because Jump 
> only jumps even halfwords.
>
> - You want a confession? You know one reason why I got in the habit of not 
> using DS 0H in code? Because when I started out with punched card decks, 24MB 
> hard drives and Assembler D, every transition from assembled data to DS and 
> back forced a new TXT card and wasted cards and/or DASD space. You may laugh 
> now. FWIW, DC 0H'0' avoided the problem but is trickier 029-jockeying than 
> EQU *, and every typo cost you your daily shot back in those days.
>
> - 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 like about it is 
> that labels invite the question "who jumps here?"* so if I can avoid a label 
> I do. It's a tradeoff. No one ever said assembler coding was for the 
> faint-hearted.
>
> *A better solution probably is the structured assembler macros but by the 
> tim

Re: EQU * considered harmful

2018-08-02 Thread Jonathan Scott

Plain DC 0H has been supported by HLASM since at least 1.3,
about 20 years ago.

Jonathan Scott, HLASM
IBM Hursley, UK

Re: EQU * considered harmful

 1. I don't have an obligation to back it up. You are free to remain ignorant.

 2. RYFM


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


From: IBM Mainframe Assembler List  on behalf 
of Steve Smith 
Sent: Thursday, August 2, 2018 12:08 PM
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 supported for a
> long
> >time, if not from the beginning of HLASM.
>
> Plain DC 0H is not supported. Plain DS 0H was supported long before z/OS,
> back in the early S/360 days.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3

Re: EQU * considered harmful

2018-08-02 Thread Steve Smith

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 wander off somewhere?

Not that I want to come off snarky, but IBM provides plenty of poor coding
examples in various MACLIBs.  And, plenty of good ones too, but you have to
use some judgement.

sas

On Thu, Aug 2, 2018 at 12:02 PM, Phil Smith III  wrote:

> 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
>
> SOMEBDSF
>
> SOMENAME DSCL8
>
> SOMEREST EQU   *
>
>
>
> In this case, SOMEREST is the end of the defined part of the DSECT and the
> rest is some sort of free-fire zone (or mapped by other DSECTs, or
> whatever). I've done that a million times, never regretted it; IBM does it
> all the time. What's wrong with it?
>
>
>
> .phsiii (this is fun!)
>

-- 
sas

Re: EQU * considered harmful

2018-08-02 Thread Charles Mills

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 * considered harmful

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

SOMEBDSF

SOMENAME DSCL8

SOMEREST EQU   *

In this case, SOMEREST is the end of the defined part of the DSECT and the
rest is some sort of free-fire zone (or mapped by other DSECTs, or
whatever). I've done that a million times, never regretted it; IBM does it
all the time. What's wrong with it?

.phsiii (this is fun!)

Re: EQU * considered harmful

> In any case, plain DC 0H (or any other unit) has been supported for a long
>time, if not from the beginning of HLASM. 

Plain DC 0H is not supported. Plain DS 0H was supported long before z/OS, back 
in the early S/360 days.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~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 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 more usefully, prints the padding.  I
often want to eliminate alignment gaps.  Also, for those who care, it
doesn't break up text generation in the object deck.

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.

sas

On Wed, Aug 1, 2018 at 7:15 PM,  wrote:

> Gary,
>
> I discontinued the use of -
>
> label   DS  0H
>
> in lieu of -
>
> label   DC  0H'0'
>
> long ago.
>
> As best as I can recall, there was a bug identified (subsequently
> corrected (?)) where the buffer into which code was assembled was not
> always initialized to zeroes, and it was possible to have memory locations
> skipped over by virtue of alignment issues contain random data.
>
> The use of " DC " in lieu of " DS " ensures that memory locations skipped
> over by virtue of alignment are initialized to zeroes.
>
> John P. Baker
>

Re: EQU * considered harmful

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

SOMEBDSF

SOMENAME DSCL8

SOMEREST EQU   *

 

In this case, SOMEREST is the end of the defined part of the DSECT and the rest 
is some sort of free-fire zone (or mapped by other DSECTs, or whatever). I've 
done that a million times, never regretted it; IBM does it all the time. What's 
wrong with it?

 

.phsiii (this is fun!)

Re: EQU * considered harmful

2018-08-02 Thread Charles Mills

Actually, DS does sort of guarantee what is there -- whatever was there before. 
Consider the following (and I would *never* do this sort of thing anymore!) -- 
and watch out for deleted line breaks -- the example should be 5 lines of code:

DC C'ABC'
ORG *-3
DC C'X'
DS C
DC C'Z'

The area 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 harmful

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 more usefully, prints the padding.  I
often want to eliminate alignment gaps.  Also, for those who care, it
doesn't break up text generation in the object deck.

Re: EQU * considered harmful

2018-08-02 Thread Steve Smith

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 more usefully, prints the padding.  I
often want to eliminate alignment gaps.  Also, for those who care, it
doesn't break up text generation in the object deck.

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.

sas

On Wed, Aug 1, 2018 at 7:15 PM,  wrote:

> Gary,
>
> I discontinued the use of -
>
> label   DS  0H
>
> in lieu of -
>
> label   DC  0H'0'
>
> long ago.
>
> As best as I can recall, there was a bug identified (subsequently
> corrected (?)) where the buffer into which code was assembled was not
> always initialized to zeroes, and it was possible to have memory locations
> skipped over by virtue of alignment issues contain random data.
>
> The use of " DC " in lieu of " DS " ensures that memory locations skipped
> over by virtue of alignment are initialized to zeroes.
>
> John P. Baker
>

Re: EQU * considered harmful

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"!

Re: EQU * considered harmful

2018-08-02 Thread Charles Mills

Ooh. Don't know if I like that or if the "WTF?" factor for *+8 as a "label"
is too great.

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 7:02 AM
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 less
intuitive (change A to AG and there goes your J *+8). What I like about it
is that labels invite the question "who jumps here?"* so if I can avoid a
label I do. It's a tradeoff. No one ever said assembler coding was for the
faint-hearted.

 

I did that until recently (like a year ago), when somebody convinced me it
was evil. Well, convinced me enough to stop; I sort of agree that if you
can't handle it, don't be doin' no assembler, but I still stopped. I used to
use this format:

 TM   FLAG,BIT

 JO   *+8

 LR1,WHATEVER

*+8  DS   0H

 

That made it clear where it was going and thus made it harder (I think) to
insert stuff blindly, while not encouraging anyone else to branch there :)

 

...phsiii

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 less intuitive (change 
>A to AG and there goes your J *+8). What I like about it is that labels invite 
>the question "who jumps here?"* so if I can avoid a label I do. It's a 
>tradeoff. No one ever said assembler coding was for the faint-hearted.

 

I did that until recently (like a year ago), when somebody convinced me it was 
evil. Well, convinced me enough to stop; I sort of agree that if you can't 
handle it, don't be doin' no assembler, but I still stopped. I used to use this 
format:

 TM   FLAG,BIT

 JO   *+8

 LR1,WHATEVER

*+8  DS   0H

 

That made it clear where it was going and thus made it harder (I think) to 
insert stuff blindly, while not encouraging anyone else to branch there :)

 

...phsiii

Re: EQU * considered harmful

2018-08-01 Thread Gord Tomlin


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/

Re: EQU * considered harmful

2018-08-01 Thread Steve Thompson

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 doing Univac -- as I recall the U1100/x machines were word 
machines. Each instruction was 36bits long and there were 3 
types of registers. General, FP, and Index IIRC.


Answering another post here: The instruction and data being close 
together such that they are in the same cache line causes what I 
think is called a processor pipeline stall. With the G3 CMOS 
chip-set that implemented I/D Bank cache, if an instruction were 
to modify data within that cache line, the pipe would stall, the 
system control code would have to force that cache line back into 
C-Store, it would have to be fetched into the D-Bank cache, the 
data fetch/update/write (whatever the instruction was) would be 
done, the cache line would be flushed back to C-store and then 
re-fetched back into the I Bank cache


That was the G3 level. I'm told that this was uncovered by SAS 
because they were "generating" their code as they ran (I'm 
thinking they were modifying their code) and so SAS programs ran 
much more slowly than they had on the prior machine.


One observation I have as someone who has been programming in 
BAL/ALC since about 1976. You guys wouldn't be able to program on 
a S/360 with that level of assembler. Particularly if it were the 
DOS Assembler.


The idea of EQU * in instructions made sense, and as others have 
pointed out, didn't cause excessive TXT cards to be punched 
(really had to pay attention to this on a S/360-20 -- oh the 
inhumanity of it all with a SYSRES on tape -- My apologies to 
Bones of Star Trek fame).


And structured ALC macros generate scads of unintelligible labels 
(well, until you get used to the way it works). Be glad that we 
can now use more than 8 characters for a label.


There are reasons for labels that one does not "branch" to, 
whether by LA Rn,=(sss); BR Rn, or BALR, etc. And that is, if one 
is using an interactive trace tool (such as TSO TEST -- I have 
forgotten how to use it, XDC is so much better) one can specify 
the PARM of TEST to the assembler and was it also LINKEDIT?


Anyway, you now have labeled points (on SYM cards) to set 
breakpoints instead of offsets in the program.


Ya just gotta be old enough to have had to work that way back in 
the day.


And Charles, sorry, this go around I will be in the office. I 
just can't get free to go to SHARE. Maybe, possibly in spring 2019.


Regards,
Steve Thompson


On 08/01/2018 06:49 PM, Charles Mills wrote:

- IBM is pretty much committed to even-halfword instructions because Jump only 
jumps even halfwords.

- You want a confession? You know one reason why I got in the habit of not 
using DS 0H in code? Because when I started out with punched card decks, 24MB 
hard drives and Assembler D, every transition from assembled data to DS and 
back forced a new TXT card and wasted cards and/or DASD space. You may laugh 
now. FWIW, DC 0H'0' avoided the problem but is trickier 029-jockeying than EQU 
*, and every typo cost you your daily shot back in those days.

- 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 like about it is that labels invite the question "who jumps here?"* so 
if I can avoid a label I do. It's a tradeoff. No one ever said assembler coding was for 
the faint-hearted.

*A better solution probably is the structured assembler macros but by the time 
they came along I was not writing much assembler, so this old dog never learned 
that new trick.

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, 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, Distinguished Engineer, IBM z Systems Microprocessor 
Development (March 2016)

Charles


Exactly.

"Mixing executable code and operand data considered harmful"

And if you always avoid mixing instructions and operand data, using EQU
* for labels in code is no longer potentially harmful. We're on pretty
safe ground if we assume IBM will always only create instructions that
are an even number of bytes in size. I prefer, and always use, DS 0H for
labels in code, but if EQU * causes problems in your code you have other
things to clean up.

Here's one to

Re: EQU * considered harmful

2018-08-01 Thread jbaker

Gary,

I discontinued the use of -

label   DS  0H

in lieu of -

label   DC  0H'0'

long ago.

As best as I can recall, there was a bug identified (subsequently corrected 
(?)) where the buffer into which code was assembled was not always initialized 
to zeroes, and it was possible to have memory locations skipped over by virtue 
of alignment issues contain random data.

The use of " DC " in lieu of " DS " ensures that memory locations skipped over 
by virtue of alignment are initialized to zeroes.

John P. Baker

-Original Message-
From: IBM Mainframe 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  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.
>
> 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 "length" to each bit, and use that as an offset 
> in the field, e.g:
>
> FLAGSDSXL4
> F_OPEN   EQU   X'80',0
> F_CLOSE   EQU   X'40',0
> F_FUBAR  EQU   X'02',3
> ...
>   TMFLAGS+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
>   TMBYTE,BIT
>   BCR   X'01',7
>   ...
>   other instructions
> HI_MOM DCC'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.

Re: EQU * considered harmful

2018-08-01 Thread Paul Gilmartin

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 a boon here.  How many "B *+12" in SYS1.MACLIB ought to be replaced
with   But this clutters the cross-reference listing.

Long ago I worked with a simple Pascal compiler.  It didn't generate assembler
code, but branches to hard-coded offsets were endemic, and caused "tire fire"
when I changed the code generation.  Finally, I took the effort to ferret out
every one to defer calculating the offset and backfill from the target.  Mostly
piggybacked on existing logic for resolving GOTO displacements.

-- gil

Re: EQU * considered harmful

- IBM is pretty much committed to even-halfword instructions because Jump only 
jumps even halfwords.

- You want a confession? You know one reason why I got in the habit of not 
using DS 0H in code? Because when I started out with punched card decks, 24MB 
hard drives and Assembler D, every transition from assembled data to DS and 
back forced a new TXT card and wasted cards and/or DASD space. You may laugh 
now. FWIW, DC 0H'0' avoided the problem but is trickier 029-jockeying than EQU 
*, and every typo cost you your daily shot back in those days.

- 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 like about it is that labels invite 
the question "who jumps here?"* so if I can avoid a label I do. It's a 
tradeoff. No one ever said assembler coding was for the faint-hearted.

*A better solution probably is the structured assembler macros but by the time 
they came along I was not writing much assembler, so this old dog never learned 
that new trick.

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, 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, Distinguished Engineer, IBM z Systems Microprocessor 
> Development (March 2016)
> 
> Charles

Exactly.

"Mixing executable code and operand data considered harmful"

And if you always avoid mixing instructions and operand data, using EQU 
* for labels in code is no longer potentially harmful. We're on pretty 
safe ground if we assume IBM will always only create instructions that 
are an even number of bytes in size. I prefer, and always use, DS 0H for 
labels in code, but if EQU * causes problems in your code you have other 
things to clean up.

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.

Re: EQU * considered harmful

2018-08-01 Thread Gord Tomlin


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, Distinguished Engineer, IBM z Systems Microprocessor 
Development (March 2016)

Charles


Exactly.

"Mixing executable code and operand data considered harmful"

And if you always avoid mixing instructions and operand data, using EQU 
* for labels in code is no longer potentially harmful. We're on pretty 
safe ground if we assume IBM will always only create instructions that 
are an even number of bytes in size. I prefer, and always use, DS 0H for 
labels in code, but if EQU * causes problems in your code you have other 
things to clean up.


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.

--

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/

Re: EQU * considered harmful

2018-08-01 Thread Phil Smith III

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 personally prefer the "look" of EQU * over DS/DC 0? that's your

>prerogative.  But your preference is for a symbol with no type, no

>alignment, and a default length.  I think you could get over it if you

>tried.

Ooh, I loves me a good theological argument!

I disagree that DS 0X is somehow better. EQU * says "Here, damnit, just a pin 
in the ground", and when that's what you want, is thus preferable; DS 0X 
implies a bit more (to me at least). In fact, I've always slightly disliked DS 
0H on labels, despite having used it religiously for the last 38.5 years of 
writing assembler. I'd be happier if there was a LABEL pseudo-instruction that 
did the same thing, but required a label. Then it would be 100% clear "This 
here thingy is a label, that's all!" (Yes, I could use a macro, but.) So yes, 
an EQU * could "easily be replaced", but not necessarily winding up with 
something better.

Semi-OT ramble warning:

Long ago and far away I had to take a Commodore SuperPet assembler course. I 
had been writing 370 assembler for several years at that point, doing systems 
work on VM/SP, so the toy assembler was not much of a challenge.

For our final project, we had to write a stupid game. Mine mostly worked: I 
couldn't be arsed to take the time to count stuff, so it was a wee bit confused 
about screen boundaries, would wrap sometimes by one pixel (or more like one 
character-wasn't exactly an APA display). But the basics were right, and it was 
submitted as code, not a demo.

I got a 48 out of 50. The TA who marked it deducted two points: one for having 
subroutines that tested a single thing and returned a condition code as an 
indicator (he wanted an actual value), and one for using the equivalent of EQU 
* on labels (there was no DS 0H). He said the latter was "unnecessary", 
couldn't explain why the former was bad.

I complained to the professor (Wes Graham, whom you have likely heard 
of-WATFOR, WATFIV, WATCOM) who shrugged and said "48/50 is a pretty good 
grade". And at that point, I dropped out of computer science, concluding that 
the "teaching" was a waste of my time. Mind you, I already knew Graham was 
mostly a fraud (shh, I know, we don't talk about that).

The funniest part was that a buddy in the class, who was up all night making 
his program work perfectly, got 45/50. He was most unhappy about my grade!

I suppose it's time to let this go, eh? It's been 35+ years and Graham has been 
dead for almost 20 of 'em.

...phsiii

Re: EQU * considered harmful

2018-08-01 Thread Steve Smith

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

Re: EQU * considered harmful

2018-08-01 Thread Steve Smith

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 DS/DC 0? that's your
prerogative.  But your preference is for a symbol with no type, no
alignment, and a default length.  I think you could get over it if you
tried.

sas

Re: EQU * considered harmful

"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, Distinguished Engineer, IBM 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

Inline data is only a killer if it is updated.  It is merely less efficient if 
it is read only (same cache line in instruction and data caches).

My example was merely to show that the "INSTRUCT" statement would force half 
word alignment.  Aside from macros that expand inline CONSTANTS (not updatable 
areas), I generally avoid mixing instructions and data.  Even in non-reentrant 
code (unfortunately there's a lot here that I have to maintain and it's not 
worth it to make it reentrant), I try to isolate code blocks and data blocks.

Keith Moe
BMC Software, 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 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'' because the Opcode does not have a
 mnemonic), the ACONTROL function could be used to avoid the
 warning. 
 
 Keith Moe
 BMC Software, Inc.

Re: EQU * considered harmful

2018-08-01 Thread Keith Moe

Inline data is only a killer if it is updated.  It is merely less efficient if 
it is read only (same cache line in instruction and data caches).

My example was merely to show that the "INSTRUCT" statement would force half 
word alignment.  Aside from macros that expand inline CONSTANTS (not updatable 
areas), I generally avoid mixing instructions and data.  Even in non-reentrant 
code (unfortunately there's a lot here that I have to maintain and it's not 
worth it to make it reentrant), I try to isolate code blocks and data blocks.

Keith Moe
BMC Software, 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 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'' because the Opcode does not have a
 mnemonic), the ACONTROL function could be used to avoid the
 warning. 
 
 Keith Moe
 BMC Software, Inc.

Re: EQU * considered harmful

2018-08-01 Thread Seymour J Metz

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
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf 
of Steve Smith 
Sent: Wednesday, August 1, 2018 12:34 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: EQU * considered harmful

EQU * is a very common idiom in assembler programming.  I'd like to submit
for your consideration that it is wrong, 100% of the time.

Any symbol referencing memory should always be defined with DS/DC, so the
correct alignment can be specified.  * per se, is a very useful concept,
just not on EQU.  But as far as I can see, every EQU * is a bug, either
latent or actual.

The most acceptable usage would be to generate the length of an area (*-X),
but even that can easily be done by defining an 'end' symbol, so that EQU
X-Y is available.

If I'm overlooking something, I hardly have to ask... but tell me if
there's no better way for some example.

--
sas

Re: EQU * considered harmful

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'' 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  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 
   DSX
 > 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 "length" to each bit, and use that as an
 offset in the field, e.g:
 >
 > FLAGSDSXL4
 > F_OPEN   EQU   X'80',0
 > F_CLOSE   EQU   X'40',0
 > F_FUBAR  EQU   X'02',3
 > ...
 >  
 TMFLAGS+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
 > 
  TMBYTE,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

Re: EQU * considered harmful

2018-08-01 Thread Keith Moe

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'' 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  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.

Re: EQU * considered harmful

2018-08-01 Thread Paul Gilmartin

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 trouble.  E.g:
>  
This happened to us when we changed the length of our boilerplate copyright
notice.  The remedy was to add "DS 0H" to the end of that COPY member.
I considered this overkill and argued against it because it might add a byte
to half our load modules, whether they needed it or not.

Those source members that started with Branch to an instruction were unaffected;
those that started with Branch to "DS 0H" were at risk.

I was outvoted; storage is cheap nowadays.

-- gil

Re: EQU * considered harmful

2018-08-01 Thread Richard Kuebbing

It's been a long time but once upon a time DS 0H was used for labels in code 
for two reasons.  TSO TEST liked it better than EQU *, and when a person mixed 
data and code, EQU * could possibly refer to an odd address.

And yes EQU * is a good way to mark a location in a record/control block 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 * considered harmful

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.
>
> 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 "length" to each bit, and use that as an offset 
> in the field, e.g:
>
> FLAGSDSXL4
> F_OPEN   EQU   X'80',0
> F_CLOSE   EQU   X'40',0
> F_FUBAR  EQU   X'02',3
> ...
>   TMFLAGS+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
>   TMBYTE,BIT
>   BCR   X'01',7
>   ...
>   other instructions
> HI_MOM DCC'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. 



- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you

Re: EQU * considered harmful

2018-08-01 Thread Tony Thigpen


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 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 "length" to each bit, and use that as an offset 
in the field, e.g:

FLAGSDSXL4
F_OPEN   EQU   X'80',0
F_CLOSE   EQU   X'40',0
F_FUBAR  EQU   X'02',3
...
  TMFLAGS+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
  TMBYTE,BIT
  BCR   X'01',7
  ...
  other instructions
HI_MOM DCC'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).

Re: EQU * considered harmful

2018-08-01 Thread Gary Weinhold

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.

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 "length" to each bit, and use that as an offset
in the field, e.g:

FLAGSDSXL4
F_OPEN EQU X'80',0
F_CLOSE EQU X'40',0
F_FUBAR EQU X'02',3
...
TMFLAGS+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
TMBYTE,BIT
BCR X'01',7
...
other instructions
HI_MOM DCC'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.

Re: EQU * considered harmful

2018-08-01 Thread Dan Greiner

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 "length" to each bit, and use that as an offset 
in the field, e.g:

FLAGSDSXL4
F_OPEN   EQU   X'80',0
F_CLOSE   EQU   X'40',0
F_FUBAR  EQU   X'02',3
...
 TMFLAGS+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
 TMBYTE,BIT
 BCR   X'01',7
 ...
 other instructions
HI_MOM DCC'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).

Re: EQU * considered harmful