Not wanting to get into a 'religious' war, but also giving IBM some recognition, most instructions are handled at the chip level, not milli-code level. Only the most complex are handled as milli-code because of the overhead to run a milli-code instruction. Switching from normal mode to milli-code mode and back involves saving and restoring registers, setting up milli-code registers and a whole bunch of other things. It is amazing how many instructions they have gotten on to the chip to avoid milli-code.
Things like MVI and MVIY are probably the same silicon circuits for the executor phase, but a different set of silicon for the address resolution phase. I expect there are two sets of address resolution silicon, one for base + 12 bits and one for base + 20 bits that are shared across many instuctions. MVC is a whole different set of silicon than MVI/MVIY, but still on the chip. MVCL is a milli-code implementation, and it's performance for less than 32K of data shows it. There are lots of parts to a processor, fetch/decode/address resolution/operand fetch/put away, but each part has to work in 1 to three cycles. I find machine architecture fascinating, but I have enough on my hands with DB2 that I don't spend as much time as I'd like understanding the hardware. Chris Blaicher From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of David Cole Sent: Tuesday, August 31, 2010 2:23 PM To: [email protected] Subject: Re: number of new instructions At 8/31/2010 12:49 PM, John P. Baker wrote: To me, the only valid count of instructions is that which one arrives at be recognizing distinct binary operations codes. Oh, that's just silly. There is a large(!) gray area... where whether a given bit is part of an opcode or an operand is just a matter of point of view. Consider the classic group of BC instructions: BZ is X'478-' while BNZ is X'477-'. Are these two things distinct machine instructions? Or are they two flavors of just one instruction (BC, X'47--')? I would say that (like photons and light waves) both views are useful. It just a matter of context as to which view is more useful at a given moment. It has already been pointed out in this thread that "MVI, MVIY, and MVC [are just] variants of a generic MOVE instruction". We don't see it because from our (external) point of view, that's all under the covers, but that does not make it any less true or any less relevant. But IBM (as they constantly do) just keeps blurring the lines. Consider the new instruction (published at SHARE) name RISBHG. It's opcode is X'EC...5D'. So far, so good. But then IBM threw in a variation: RISBHGZ's opcode is X'EC...z...5D' (where "z" is bit #24 of the instruction.) The difference between the two instructions is whether this "z" bit is on (RISBHGZ) or off (RISBHG). Ok, that's not strictly true, since RISBHGZ is actually a subset of RISBHG, since in RISBHG the "z" bit can be either on or off. But IBM could easily have also implemented something like "RISBHO" where the "z" bit would be defined as being off. (They didn't, but they could have.) Then the difference between RISBHGZ and RISBHGO would exactly be the "z" bit. So is the "z" bit an opcode bit? or an operand bit? Let the Religious Wars begin! And what about RISBHG (X'EC...5D') vs. RISBLG (X'EC...51')? In our classic view, they have distinct opcodes, but those opcodes differ by only a couple of bits. Couldn't those bits be usefully viewed as just being operands that indicate whether the instruction's target is the high half or low half of a register? After all, under the covers these two "distinct" instructions are almost certainly nothing more than two different inputs to the same handing routine. I really don't see any categorical difference between RISBHG-vs-RISBLG and RISBHGZ-vs-RISBHGO (and BZ-vs-BNZ for that matter). It's all just bits affecting actions. Which bits are opcode and which are operand is often just a matter of opinion and convenience with respect to a specific need. Continuing. Consider LHHR, LHLR, LLHFR, LLHHHR, LLHHLR, LLHLHR, LLCHHR, LLCHLR and LLCLHR. These instructions are all variations on copying words and halfwords between the low and high halves of 64-bit registers. But in the classic view, they are not distinct machine instructions. They all are specific variations of RISBHGZ and RISBLGZ (which themselves are variations of RISBHG and RISBLG. [Which themselves are probably two different inputs to the same millicode handler.]) "LLHHLR r1,r2" for example is "RISBHGZ r1,r2,16,31,32." In effect, LLHHLR is an instruction that has a 5-byte opcode! BTW: The new opcodes mentioned above are all published at " http://share.confex.com/share/115/webprogram/Session7034.html ". Finally, FWIW, I currently am working on adding to z/XDC knowledge about the new machine instructions. Obviously, at the heart of z/XDC's machine instruction parser is a rather large table that describes each "opcode". For the purposes of this table, "opcodes" are defined to be selectable bits from up to three bytes (any bytes) of a machine instruction. This means (among other things) that: - "Extended mnemonics" are parsed as distinct opcodes. - I cannot (yet) support mnemonics that require 4 or 5 opcode bytes for their definition. (IBM always has a way of making me feel shortsighted...) At this point, my table has definitions for 1319 distinct mnemonics. This includes many (but not all) obsolete instructions. (Some obsolete opcodes have actually been reused by IBM for newer instructions.) Dave Cole REPLY TO: [email protected] ColeSoft Marketing WEB PAGE: http://www.colesoft.com <http://www.colesoft.com/>736 Fox Hollow Road VOICE: 540-456-8536 Afton, VA 22920 FAX: 540-456-6658
