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
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
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
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
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 DS 0H in code? Because when I
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
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: Instruction/Data Cache Usage (was EQU *)
On 2018-08-02, at 11:27:28, Charles Mills wrote: >> Can EX modify the CC mask in a target branch instruction? > > You bet! > Branch prediction is always ... well, like any other prediction. > It was mentioned in IBM-MAIN that BCT(R) is predicted to always branch; BC is predicted to never branch. I hope there's an exception for BC 15: EX targets, syscall arguments, etc. If so, I wondered if: BC cond,target Highly probable branch, but predicted not to branch Might be better optimized as: BC 15-cond,*+8 Probable not branch; correctly predicted BC 15,targetPredictably certain to branch. (JIT compilation is supposed to fix things like this.) -- gil
Re: Instruction/Data Cache Usage (was EQU *)
> Can EX modify the CC mask in a target branch instruction? You bet! Branch prediction is always ... well, like any other prediction. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, August 2, 2018 10:09 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Instruction/Data Cache Usage (was EQU *) On 2018-08-02, at 08:22:52, Alan Atkinson 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" > > Is that also now true for the target of an execute perchance? > Surely this is model-dependent. On S/360, I doubt it mattered. > We went through a whole exercise to get rid of all the > > EX *+8 > J *+?? > > A principal use of EX is to be able to use a register mask to modify the target. CDC 3800 had a clever alternative to this, a modify-next-instruction instruction (I forget what it was called). The target was always the following instruction; execution continued after that instruction -- no need to branch around. Its principal use was to enable CDC 3800 extended addressing in old CDC 3600 short-address instructions. Addressing was not otherwise modal. IBM might have done well to provide a modify-next rather than a long-address, pipeline breaking, dreadfully expensive, EX. (They probably had the discussion and had good reasons not to do it.) (Can EX modify the CC mask in a target branch instruction? A sure branch prediction breaker.) -- gil
Re: Instruction/Data Cache Usage (was EQU *)
On 2018-08-02, at 08:22:52, Alan Atkinson 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" > > Is that also now true for the target of an execute perchance? > Surely this is model-dependent. On S/360, I doubt it mattered. > We went through a whole exercise to get rid of all the > > EX *+8 > J *+?? > > A principal use of EX is to be able to use a register mask to modify the target. CDC 3800 had a clever alternative to this, a modify-next-instruction instruction (I forget what it was called). The target was always the following instruction; execution continued after that instruction -- no need to branch around. Its principal use was to enable CDC 3800 extended addressing in old CDC 3600 short-address instructions. Addressing was not otherwise modal. IBM might have done well to provide a modify-next rather than a long-address, pipeline breaking, dreadfully expensive, EX. (They probably had the discussion and had good reasons not to do it.) (Can EX modify the CC mask in a target branch instruction? A sure branch prediction breaker.) -- gil
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
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
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 > time they came along I was not writing much assembler, so this old dog never > learned that new trick. > >
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
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
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
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
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
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: Instruction/Data Cache Usage (was EQU *)
On 2018-08-02 10:22 AM, Alan Atkinson wrote (snipped): If it's not necessary we can go back to being able to see what you meant to do without scrolling. Could that be accomplished with a comment on the EX statement? Of course to prevent the comment from getting out of date, you'd have to use a hyperlink back to the actual target. And then you'd have to implement hyperllink resolution in the ISPF editor. 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: 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" Is that also now true for the target of an execute perchance? We went through a whole exercise to get rid of all the EX *+8 J *+?? in the code a few years back in the name of efficiency We needed to do it after the way pipelining was handled changed between machines - it made a huge difference to performance inside a very very active chunk of code. It was enough to affect the entire machine throughput. If I was mildly less demented I'd recall the machine versions (I'm sorta thinking going from a Z9 to a Z11) but it was a few years back. If it's not necessary we can go back to being able to see what you meant to do without scrolling. I haven't looked at MF architecture in a couple of years so I'm a bit behind the times in this area.
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: Instruction/Data Cache Usage (was EQU *)
The IBM z Systems Processor Optimization Primer v2 by C. K. Shum supports your assertion. One could argue that grouping all literals/constants so they are only in the D-cache and not in I-cache is a slightly more efficient use of total cache, assuming other literals/constants in that D-cache line will also be referenced. But it's probably a moving target; i believe I recall that I read/heard that the translation table referenced by TRT will be placed in I-cache. On 2018-08-01 9:17 PM, Christopher Y. Blaicher wrote (snipped): 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. 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
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: Instruction/Data Cache Usage (was EQU *)
Well, yes, as a matter of fact, I mentioned it in an e-mail to you and an associate of yours on December 13, 2016. I did not request nor did I expect some sort of "resolution" from IBM. I of course would never expect that my macro would automagically support some new MODESET feature. It is not named MODESET so the lack of the feature should not boggle my successor, whoever he or she may be. > Most developers choose not to spend their time looking for "what did my > predecessor do that works but could have been done better". Of course. Including me. As I said "I know it is nothing but it just annoyed me ..." The paragraph was about an oddity in me, not an oddity in z/OS. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Thursday, August 2, 2018 6:44 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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. Did you ever mention that to anyone who might have been able to address your disfavor? I suspect not. Having our own MODESET macro, you'd be unhappy if MODESET ever chose to use any of the first 16 bits of its flag word, if you ever wanted to use whatever new option did so. And of course the macro was written years (decades?) before LHI was available and, until there was no chance of someone using that macro to run on an older system, changing to LHI would have been unacceptably incompatible. Most developers choose not to spend their time looking for "what did my predecessor do that works but could have been done better". So if there's any chance of it getting changed, you'd have to bring it to our attention. Would it have been done? Who knows. Will it be done? Maybe. I can at least say that we no longer feel there to be any impediment to unconditionally using anything in base z/Architecture (and of course the relative/immediate instruction set pre-dates that). We will not typically use by default instructions that correspond to a release's architecture level set, because a product might compile with the "new release macros" but run on an older release. But if dual-pathing were deemed worthwhile, the macro could rely on the SYSSTATE ARCHLVL value set by a program. Peter Relson z/OS Core Technology Design
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: 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. Did you ever mention that to anyone who might have been able to address your disfavor? I suspect not. Having our own MODESET macro, you'd be unhappy if MODESET ever chose to use any of the first 16 bits of its flag word, if you ever wanted to use whatever new option did so. And of course the macro was written years (decades?) before LHI was available and, until there was no chance of someone using that macro to run on an older system, changing to LHI would have been unacceptably incompatible. Most developers choose not to spend their time looking for "what did my predecessor do that works but could have been done better". So if there's any chance of it getting changed, you'd have to bring it to our attention. Would it have been done? Who knows. Will it be done? Maybe. I can at least say that we no longer feel there to be any impediment to unconditionally using anything in base z/Architecture (and of course the relative/immediate instruction set pre-dates that). We will not typically use by default instructions that correspond to a release's architecture level set, because a product might compile with the "new release macros" but run on an older release. But if dual-pathing were deemed worthwhile, the macro could rely on the SYSSTATE ARCHLVL value set by a program. Peter Relson z/OS Core Technology Design
