>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 <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Steve Thompson <ste...@copper.net> 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. > > 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. >
