David,
It is not "silly". It is just a different point of view. You refer to the "extended mnemonics" for BC, BRC, RISBHG, RISBLG, etc. IBM specifically documents the "operation code". Mask bits, etc., may be hidden by various "extended mnemonics" provided by HLASM, but that does not change the underlying instruction. I prefer to go by what the "Principles of Operation" publication documents as distinct instructions. John P. Baker From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of David Cole Sent: Tuesday, August 31, 2010 3:23 PM To: [email protected] Subject: Re: number of new instructions 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> 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
