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