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.
