Re: EQU * considered harmful
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: Instruction/Data Cache Usage (was EQU *)
On 2018-08-01, at 21:29:05, Keven wrote: > > Hmm,My last post wasn’t formatted correctly in my mail reader > so I’ll try it again. There should be three separated lines of text > following. The last line should be indented relative to the penultimate line. > PERTURBED_BY_THIS CLC THIS,THAT > PREFER DS 0H CLC THIS,THAT > Still No Good, despite teeming NBSP. Curse you, Outlook for Handhelds! (Might there be a native mail client for your handheld better than Outlook? Or would it be even worse?) > On Wed, Aug 1, 2018 at 10:18 PM -0500, "Keven" wrote: > > In general I think code labels should be associated with locations and not > specific instructions although it seems appropriate to label instructions > that are the target of Execute. > PERTURBED_BY_THIS CLC THIS,THAT > PREFER DS 0H CLC THIS,THAT -- gil
Re: Instruction/Data Cache Usage (was EQU *)
From: "Christopher Y. Blaicher" Sent: Thursday, August 02, 2018 11:17 AM Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache. A comment on the original EQU * part of this thread. I prefer the DS 0H to hold a label because you can't get burned on someone putting something in front of it that isn't halfword aligned. I personally HATE it when people put a label on an instruction, especially if they are using long names in the label. All the other op codes are in column 10 and then you have one out in right field. Your eye can't just flow down the screen, now you have to go searching for the op code. Also putting a label on an instruction makes it harder to move the instruction. And with good reason. A labelled instruction usually means that it is the head of a loop or the object of a branch. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Instruction/Data Cache Usage (was EQU *)
Hmm,My last post wasn’t formatted correctly in my mail reader so I’ll try it again. There should be three separated lines of text following. The last line should be indented relative to the penultimate line. PERTURBED_BY_THIS CLC THIS,THAT PREFER DS 0H CLC THIS,THAT On Wed, Aug 1, 2018 at 10:18 PM -0500, "Keven" wrote: Chris, I share your dislike for labeled instructions, albeit with somewhat less passion in that my perturbation falls short of all-caps animus. In general I think code labels should be associated with locations and not specific instructions although it seems appropriate to label instructions that are the target of Execute. PERTURBED_BY_THIS CLC THIS,THAT PREFER DS 0H CLC THIS,THAT My tuppence-ha’penny worth Keven On Wed, Aug 1, 2018 at 8:33 PM -0500, "Christopher Y. Blaicher" wrote: Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache. A comment on the original EQU * part of this thread. I prefer the DS 0H to hold a label because you can't get burned on someone putting something in front of it that isn't halfword aligned. I personally HATE it when people put a label on an instruction, especially if they are using long names in the label. All the other op codes are in column 10 and then you have one out in right field. Your eye can't just flow down the screen, now you have to go searching for the op code. Also putting a label on an instruction makes it harder to move the instruction. My 2 cents. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Wednesday, August 1, 2018 7:54 PM To: MVS List Server 2 Subject: Re: Instruction/Data Cache Usage (was EQU *) My favorite (not!) is MODESET which generates (IIRC) in-line data and a branch around it and a LOAD from storage. I know it is nothing but it just annoyed me so much that I created my own that uses LHI and no branch. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keith Moe Sent: Wednesday, August 1, 2018 3:58 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Instruction/Data Cache Usage (was EQU *) "(working storage or stack storage)" I interpret this is mean storage that is being ALTERED, not CONSTANTS. I would think that duplicate unchanged cache lines in the instruction and data caches would not have the same SERIOUS penalty as altering data would. But I am not a hardware engineer nor do I know if this is true or not. I've noticed that IBM has been changing many of their macros to generate fewer inline constants with branches around them and use more literals (which can sometime surprise you with unexpected addressability problems when the data suddenly move from being very local) presumably to reduce the double cache usage (with or without the move/copy penalty), but one of the most glaring mixture of instructions and data that is (potentially) updated are the CVTEXIT and CVTBRET instructions. Programs invoked via system linkage have Register 14 pointing to CVTEXIT. The CVT is in the read/write nucleus and is not even cache line aligned!
Re: Instruction/Data Cache Usage (was EQU *)
Chris, I share your dislike for labeled instructions, albeit with somewhat less passion in that my perturbation falls short of all-caps animus. In general I think code labels should be associated with locations and not specific instructions although it seems appropriate to label instructions that are the target of Execute. PERTURBED_BY_THIS CLC THIS,THAT PREFER DS 0H CLC THIS,THAT My tuppence-ha’penny worth Keven On Wed, Aug 1, 2018 at 8:33 PM -0500, "Christopher Y. Blaicher" wrote: Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache. A comment on the original EQU * part of this thread. I prefer the DS 0H to hold a label because you can't get burned on someone putting something in front of it that isn't halfword aligned. I personally HATE it when people put a label on an instruction, especially if they are using long names in the label. All the other op codes are in column 10 and then you have one out in right field. Your eye can't just flow down the screen, now you have to go searching for the op code. Also putting a label on an instruction makes it harder to move the instruction. My 2 cents. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Wednesday, August 1, 2018 7:54 PM To: MVS List Server 2 Subject: Re: Instruction/Data Cache Usage (was EQU *) My favorite (not!) is MODESET which generates (IIRC) in-line data and a branch around it and a LOAD from storage. I know it is nothing but it just annoyed me so much that I created my own that uses LHI and no branch. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keith Moe Sent: Wednesday, August 1, 2018 3:58 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Instruction/Data Cache Usage (was EQU *) "(working storage or stack storage)" I interpret this is mean storage that is being ALTERED, not CONSTANTS. I would think that duplicate unchanged cache lines in the instruction and data caches would not have the same SERIOUS penalty as altering data would. But I am not a hardware engineer nor do I know if this is true or not. I've noticed that IBM has been changing many of their macros to generate fewer inline constants with branches around them and use more literals (which can sometime surprise you with unexpected addressability problems when the data suddenly move from being very local) presumably to reduce the double cache usage (with or without the move/copy penalty), but one of the most glaring mixture of instructions and data that is (potentially) updated are the CVTEXIT and CVTBRET instructions. Programs invoked via system linkage have Register 14 pointing to CVTEXIT. The CVT is in the read/write nucleus and is not even cache line aligned!
Re: Instruction/Data Cache Usage (was EQU *)
Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache. A comment on the original EQU * part of this thread. I prefer the DS 0H to hold a label because you can't get burned on someone putting something in front of it that isn't halfword aligned. I personally HATE it when people put a label on an instruction, especially if they are using long names in the label. All the other op codes are in column 10 and then you have one out in right field. Your eye can't just flow down the screen, now you have to go searching for the op code. Also putting a label on an instruction makes it harder to move the instruction. My 2 cents. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Wednesday, August 1, 2018 7:54 PM To: MVS List Server 2 Subject: Re: Instruction/Data Cache Usage (was EQU *) My favorite (not!) is MODESET which generates (IIRC) in-line data and a branch around it and a LOAD from storage. I know it is nothing but it just annoyed me so much that I created my own that uses LHI and no branch. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keith Moe Sent: Wednesday, August 1, 2018 3:58 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Instruction/Data Cache Usage (was EQU *) "(working storage or stack storage)" I interpret this is mean storage that is being ALTERED, not CONSTANTS. I would think that duplicate unchanged cache lines in the instruction and data caches would not have the same SERIOUS penalty as altering data would. But I am not a hardware engineer nor do I know if this is true or not. I've noticed that IBM has been changing many of their macros to generate fewer inline constants with branches around them and use more literals (which can sometime surprise you with unexpected addressability problems when the data suddenly move from being very local) presumably to reduce the double cache usage (with or without the move/copy penalty), but one of the most glaring mixture of instructions and data that is (potentially) updated are the CVTEXIT and CVTBRET instructions. Programs invoked via system linkage have Register 14 pointing to CVTEXIT. The CVT is in the read/write nucleus and is not even cache line aligned!
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 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
Re: Instruction/Data Cache Usage (was EQU *)
I would suggest that the reason for the moving of "IBM's" data is because of the I-Bank D-Bank cache issue (I think it is actually a processor-pipeline stall -- but I have not done this level of work since 1990 -- Yes, long before the CMOS G3 chips were announce in 1997). What I have been doing to programs that do not have to be RENT but must become AMODE 31 is use the MF=L and MF=(E,???) formats where the List version of the macro is in "working storage" of the program (not GETMAINed, but right after the Register Save area). This allows short instruction lengths and the PLIST is in a data area that can't be part of any instruction cache lines. Regards, Steve Thompson On 08/01/2018 06:57 PM, Keith Moe wrote: "(working storage or stack storage)" I interpret this is mean storage that is being ALTERED, not CONSTANTS. I would think that duplicate unchanged cache lines in the instruction and data caches would not have the same SERIOUS penalty as altering data would. But I am not a hardware engineer nor do I know if this is true or not. I've noticed that IBM has been changing many of their macros to generate fewer inline constants with branches around them and use more literals (which can sometime surprise you with unexpected addressability problems when the data suddenly move from being very local) presumably to reduce the double cache usage (with or without the move/copy penalty), but one of the most glaring mixture of instructions and data that is (potentially) updated are the CVTEXIT and CVTBRET instructions. Programs invoked via system linkage have Register 14 pointing to CVTEXIT. The CVT is in the read/write nucleus and is not even cache line aligned! 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:41 PM "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
Re: Instruction/Data Cache Usage (was EQU *)
My favorite (not!) is MODESET which generates (IIRC) in-line data and a branch around it and a LOAD from storage. I know it is nothing but it just annoyed me so much that I created my own that uses LHI and no branch. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keith Moe Sent: Wednesday, August 1, 2018 3:58 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Instruction/Data Cache Usage (was EQU *) "(working storage or stack storage)" I interpret this is mean storage that is being ALTERED, not CONSTANTS. I would think that duplicate unchanged cache lines in the instruction and data caches would not have the same SERIOUS penalty as altering data would. But I am not a hardware engineer nor do I know if this is true or not. I've noticed that IBM has been changing many of their macros to generate fewer inline constants with branches around them and use more literals (which can sometime surprise you with unexpected addressability problems when the data suddenly move from being very local) presumably to reduce the double cache usage (with or without the move/copy penalty), but one of the most glaring mixture of instructions and data that is (potentially) updated are the CVTEXIT and CVTBRET instructions. Programs invoked via system linkage have Register 14 pointing to CVTEXIT. The CVT is in the read/write nucleus and is not even cache line aligned!
Re: EQU * considered harmful
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
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
Instruction/Data Cache Usage (was EQU *)
"(working storage or stack storage)" I interpret this is mean storage that is being ALTERED, not CONSTANTS. I would think that duplicate unchanged cache lines in the instruction and data caches would not have the same SERIOUS penalty as altering data would. But I am not a hardware engineer nor do I know if this is true or not. I've noticed that IBM has been changing many of their macros to generate fewer inline constants with branches around them and use more literals (which can sometime surprise you with unexpected addressability problems when the data suddenly move from being very local) presumably to reduce the double cache usage (with or without the move/copy penalty), but one of the most glaring mixture of instructions and data that is (potentially) updated are the CVTEXIT and CVTBRET instructions. Programs invoked via system linkage have Register 14 pointing to CVTEXIT. The CVT is in the read/write nucleus and is not even cache line aligned! 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:41 PM "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
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
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
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
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
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
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
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 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
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 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
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
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
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
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
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
I don't agree. I use label EQU * in a stream of executable instructions. I think it is clearer that the label represents a point in the logic flow, not a particular instruction, especially in situations like TM some_condition JNO Not_Whatever Instructions dealing with the Whatever condition Not_Whatever EQU * TM other_condition Etc. It makes it clear that Not_Whatever is the "exit point" for dealing with Whatever, not the name of the other_condition logic block. It is less error prone if one is inserts additional instructions that follow the "whatever" logic and are not part of it. Revealing my age, I got into this habit in the days of programs on card decks. MUCH more convenient and less problematic to have every piece of "stuff" on a separate card. I also think it is perfectly fine for labeling the end of an area of storage (DSECT). Sometimes you want the length, sometimes you want the end, such as when indexing through the entries in a table. LA R5,Next_Entry is clearer to me than AHI R5,Entry_Length. Anything can be abused. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: Wednesday, August 1, 2018 9:34 AM 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
I have seen IBM DSECTS that map variable-length records, and the start of the variable part states "EQU *" Pieter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: 01 August 2018 18:34 To: 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 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: EQU * considered harmful
I very often use it to define location and length of a composite set of variables. Your END idea would not help me. And don’t we do plain constants like hash table size? Don’t think length is always known early enough. And bits in a flag byte? Rob On Wed, 1 Aug 2018 at 18:34, Steve Smith wrote: > 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 >
