>>c:=a+b
>>RISC: add a,b,c
>>CISC: mov a,c (1)
>> add b,c (2)
>>
>>When (2) depends on (1), there is no possibility for parallelization.
>>Good, you can argue that instructions on 3 operators are better than
>>the one on 2 instructions.
>
>I'm no expert, but isn't this an unfair characterization of CISC?
Yes and no.
>I know
>that MIPS uses the "add a,b,c" format and Intel uses "add a,b", but
>Intel is just one CISC architecture. I don't see any reason why you
>couldn't build a CISC processor with a three-operand format.
Me too. I wrote that it`s unfair to associate 2 op. intructions to CISC and 2
op. inst. to RISC. When RISC was introduced, this instruction format was inculed
with it, but it has nothing to do with it. The idea of RISC was to have few but
very fast commands. For that a lot of complexity (number of transitors) was
wasted to reach this goal (I assume it is so, at least it makes sense). But some
RISC machines (like Alpha) added some instructions which could be typical for
CISC. The PEER command give the middle value of 8 byte -> 1 instr. vs. 9 instr.,
this because of multimedia (MPEG).
Intel would best be served if the would introduce 3 op. instructions at Katmai
(maybe the do it ?). While in 32 bit code with 32 register 3 register each
decoded by 5 bits have space, in an 64 bit architecture with 64 register up to 8
registers could be used for computation (8x6 bit=48 bit + 16 bit for decoding
the instruction), or in IA-64 with 128 registers up to 7 registers (7x7 bit=49
bit+ 15 bit for instructions).
My conjuncture is: there is no need for 128 bit instruction code, so 64 bit
inst. code will be the final one. FPU register will stay to use 64 bit, and for
the other one I can`t say nothing. The main part of speeding up processors will
be done be using multiple processors.
greetings
Bojan
