From: mshute@cs.man.ac.uk (Malcolm Shute)
Newsgroups: alt.folklore.computers
Subject: Re: Number of instructions in microprocessors
Date: 12 Jan 93 12:51:49 GMT
Organization: Dept Computer Science, University of Manchester, U.K.

>In article <1993Jan8.120206.19712@odin.diku.dk> torbenm@diku.dk (Torben AEgidius Mogensen) writes:
>>>I'd like to know how many instructions some popular microprocessors have,
>	[ ... ]
>>This brings me back to the question: how do you count the number of
>>instructions? Do different addressing modes count as several
>>isntructions? If the assembler uses different mnemonics for
>>instructions that differ only in addressing mode (or which registers
>>are used), do they then count as several instructions?
>	[ ... ]
>>Basically I think it is impossible to find a convention for counting
>>instructions that is reasonable for all processors.

In article <1993Jan9.213253.534@ceilidh.d-and-d.com> dnichols@d-and-d.com (DoN. Nichols) writes:
>Perhaps if we agree to count each binary opcode value that results
>in a valid instruction (not counting immediate data or direct addresses,
>which are parameters, but counting everything else.)  This would deal with
>the case of assemblers which generate the same code from multiple
>instruction formats, whether byte, word, and possibly longword addressing
>was part of the instruction mnemonic or a parameter, you would still have a
>count of excactly how many *valid* instructions could be formed for that CPU
>and executed by it.

This is one of those debates which periodically comes up in comp.arch, and
everyone groans whenever it does :-)

The problem is as the first poster above writes, and the second poster attempts
to address by defining which fields in the instruction count as op-code,
and which ones count as parameter-information.  Unfortunately, one man's
definition of the divide doesn't correspond with another's.

For instance, let me ask you in which of the two classes (op-code or param-info)
would you place the following fields from an instruction:

* the bits that specify a literal constant?
    parameter-info.  No problem.

* the bits that specify an absolute address?
    parameter-info.  No problem.

* the bits that specify a register?
    parameter-info.  Must be... its just an address into a register bank,
    like the absolute address was an address into the memory bank.

* the bits that specify the addressing mode?
    Consider an iset like that of the PDP-11...
    We have decided that the bits which indicate "4" in each of the following:
    MOV #4,R0; MOV 4,R0; MOV R4,R0, MOV (R4),R0; MOV (R4)+,R0; MOV 4(R1),R0
    are to be treated as param-info, but what about the addressing mode info.
    If we treat them as op-code bits, then I have just listed 6 distinct
    instructions.  But, in that case, the following represent 6 more:
    ADD #4,R0; ADD 4,R0; ADD R4,R0, ADD (R4),R0; ADD (R4)+,R0; ADD 4(R1),R0
    and 6 more:
    CMP #4,R0; CMP 4,R0; CMP R4,R0, CMP (R4),R0; CMP (R4)+,R0; CMP 4(R1),R0
    and 6 more:
    MOVB #4,R0; MOVB 4,R0; MOVB R4,R0, MOVB (R4),R0; MOVB (R4)+,R0; MOVB 4(R1),R0
    and 6 more:
    CMPB #4,R0; CMPB 4,R0; CMPB R4,R0, CMPB (R4),R0; CMPB (R4)+,R0; CMPB 4(R1),R0
    But, this gives the PDP11 credit for having massive amounts of hardware,
    when in reality it manages to share the same hardware to perform the same
    address-mode handling in each instruction.
    Perhaps we should count addressing modes as pseudo-instructions?
    Thus, we would count MOV, ADD, SUB, CMP, INC, CLR... etc,
    and add on eight (for Rx, (Rx), (Rx)+, @(Rx)+, etc), and two for
    word or byte mode addressing, and two for the distinction between using
    an argument as a source or a destination (or should we multiply the number
    of addressing modes by two for this??)
    Or, we could just take the easy way out, and say that addressing modes
    are just flavours that can be added to the one instruction.

* the bits that specify the member of an instruction family?
    For instance, do ADD and SUB count as separate instructions?
    The answer isn't always obvious!
    It could be argued that the bit which distinguishes the op-code of ADD
    from the op-code of SUB is an addressing mode bit, causing the two's
    complement to be taken of one of the arguments.  Similarly, the distinction
    between ADD, SUB, ADC, SUBB, CLR, INC, DEC, etc.

Ultimately,
you can make a case for the whole op-code being just parameter information
to the instruction decoder... and your good intentions have resulted in every
computer ever to be classified as a 1 instruction machine!!

OK... I've taken this argument to an absurd level.
(I've done it purposely... so don't bother flaming me to point it out!!)

I merely wish to emphasise the problems with the idea of counting instructions
in an iset... and hence the reason why *still* no-one yet has come up with
a rigid definition of what is and is-not a RISC.

Incidentally... some designer attempt to get round the problem to some
extent by defining that RISC="Reduced Instruction Set Complexity"
and so get round the problem of some RISCs having more instructions (but
of a simpler, more regularly structured type) than some CISCs...
but they still do not have a rigid definition of how to measure
Instruction-Set-Complexity :-)
--

Malcolm SHUTE.         (The AM Mollusc:   v_@_ )        Disclaimer: all
Newsgroups: alt.folklore.computers