On 17 February 2013 18:45, robin <[email protected]> wrote: > From: Tony Harminc
>> One might better think of the mix of instruction encountered in a real >> world instruction stream. ED and EDMK form a minuscule fraction of all >> instructions executed, and even in a commercial environment, the >> packed decimal instructions (including CVB, CVD, PACK, and UNPK) form >> a very small portion. Indeed only the RR and RX instructions (and >> their modern counterparts) show up on any sort of ordinary graph of >> instruction use, and all others can go in the "other" bucket. > > > Some think that instruction frequency counts are the measure > of the usefulness of instructions. > > But first, you have overlooked the CISC-style instructions of the S/360. > I did not restrict that classification to just ED, EDMK, etc, > but also to RR and RX instructions like shift, multiply, divide, > the floating-point instructions that involve pre- and post-normalization > (and in particular but not restricted to multiply and divide), > decimal instructions, and most of the character instructions. Defining RISC and CISC is a bit of a mug's game. There are many people with very strong opinions on whether a particular instruction or style of instruction immediately puts an architecture into one or the other category, but equally, those peoples' opinions differ greatly on any particular feature. It is amusing, and perhaps even instructive, to read the Wikipedia article with an eye to the multiple edits and text streams as people with conflicting opinions add their view as a "However,..." to the previous one. > Using simple instruction counts tells nothing. Take the TRT instruction, > for example. To search for a single character in, say, a string of length > 256, requires one TR instruction. To do the same without TR, requires a loop > of several instructions. Multiply that by the number of iterations (up to > 256) thus could require the execution of up to 1024 instructions. > Given the choice, which would you use? Of course I usually use the TR, because it's easy to write and understand. Most compilers do not generate any TRs at all. Usually the compiler-generated code outperforms mine, unless I am writing with close attention to performance. > The TR instruction for this task runs in a fraction (perhaps 1/10th) of the > time of the loop. > Given a list of characters to search for, TR romps home in anything from > 1/20-th to 1/100-th of the time of the loop method. I'd like to see those numbers. I think you will find that TR, and many other complex and rare instructions, are interpreted by millicode streams of RR, RX, and similar instructions on a modern zArch machine. > Thus, to make a reasonable comparison of instruction frequencies, > one must use a weighted comparison, counting, say, 10 to 100, > or even 1000 times for each TR instruction, depending on what it is > searching for. Perhaps one should look at the frequency of the basic (RISCy) instructions and those used by the millicode to implement the likes of TR and EDMK. > Similarly for the other CISC-type instructions, like decimal, which you > dispense to the "other" bucket. Decimal instructions are frequent enough in commercial work that they are probably implemented by a combination of millicode and hardware assists. They are still outweighed by the RISCy ones. >> Certainly S/360 and S/370 are CISC machines from a time long predating >> the terms RISC and CISC. But for practical purposes (such as compiler >> writing or performance analysis) rather than academic taxonomy, they >> may as well be RISC. > > They are very definitely nothing like RISC. Hmmm... Many aspects of them are very much like RISC. Of course no one is suggesting that the S/360 and S/370 architectures are purely RISC. But then neither is the IBM Power purely RISC, though almost everyone calls it a a RISC architecture. > RISC machines attempt to execute each instruction in one machine cycle. > That tends to restrict the range of instructions that can be implemented > on such a machine. Such instruction sets would include integer operations > for load, add, subtract, compare, store, shift one place (though more places > could be handled in a single machine cycle), branch. However, the > instruction set > wouldn't include such luxuries as multiply, divide, etc. I think you will find it difficult to find a widely (let alone universally) accepted definition of RISC. Certainly some features, if encountered, find easy agreement that "this is not a RISC feature". But in my opinion S/360 and S/370 and their successors, even with 1000+ instructions, have many of the RISC attributes, and those attributes are very widely used, particularly by compiler generated code. Tony H.
