Nope, got it wrong. By having every instruction 4 bytes in length exactly, it speeds up code. Because you know that 32-bytes of code contain 8 instructions, and when you're executing instruction #7, say, it's time to go and get the next block of code. It also means instructions never get split up over code boundaries - for example, if your cache line was 32-bytes, with variable length instructions, what happens when an instruction starts on the last byte and carries on elsewhere? As an example, on Win98 there's a code optimizer tool that pads executable code so the instructions all end on 4K boundaries. THIS INCREASES THE SIZE OF THE FILE BUT IMPROVES SPEED OF EXECUTION.
Ahaha, good, but as you have said above, and also the author want to point out, THIS INCREASES THE SIZE OF THE FILE BUT IMPROVES SPEED OF EXECUTION. By larger file size, more memory
would be needed for operation. Chances are high that, that L1 and L2 cache won't be able to hold all the data needed for execution, thus cache miss rate will be higher. Cache miss cost CPU cycles, I think you know that, and RISC speed advantage that it should have is gone anyway.
"The necessary bits required to uniquely decode the instruction are usually found in the first 2 bytes of the instruction, 4 bytes for floating point. That's all the decoder needs to figure what this instruction is. It needs to decode the additional bytes only in cases of complex addressing modes."First of all he says they're "usually" found in the first two bytes. Then he says "that's all it needs". Then he changes mind again and says that sometimes it DOES need the rest of the instruction! Either
a) You get all the instruction, leading to increasing memory traffic, exactly what he was accusing the RISC of or
b) You don't, and when it turns out you DID need the rest of it, you're f***ed. (Well, actually it means another memory access - but you've just lost out speed-wise).
Did the author already say that it will only need to decode the whole instructions when in complex addressing mode. He also say only SOMETIMES the 68040 cip hhave to do that. The fact that all the data need for execution usually lies in first 2 ( or 4 ) bytes is quite right, especially in today processors, except sometimes. If you get all the instructions in the first 2 ( or 4 bytes ), I don't see why does it increase memory traffic because usually it don't take as much physical RAM as RISC would do.
"...could give the appearance of executing 1 instruction per cycle. Any given instruction still takes multiple clock cycles to execute, but by overlapping several instructions at once at different stages of execution, you get the appearance of one instruction per cycle."You do; on this he's quite right, if you've got enough simultaneous fetch/decode/execute subunits. He also points out this fails if the CPU is wrong about which instruction is going to be executed next (in the case of a Jump (GOTO, if you like) command). So, everybody, would would we all prefer:
a) A CPU which appears to execute 1 instruction per cycle except when it jumps, when the next few instructions will take up to 10 cycles.
b) A CPU which appears to execute 1 instruction per cycle except when it jumps, when the next few instructions will take up to 3 cycles.
Hmmm .... I'd want (b). That's the RISC.
Incidentally, JUMP instructions are fairly common in code. I've done some assembler programming as part of my course, and taking the example assembler I wrote for of the exercises, out of 17 instructions, 3 were conditional jumps. Lots of things generate jumps; calling a function, IF statements, loops, etc.
Also, he mentions exactly *how* modern CISC processors gain their speed: Multiple decoders, like you need for the above trick. What about the PIII? "Decoders 2 and 3 can decode only simple, RISC-like instructions that break down into 1 micro-op." OK: So it's fast because the extra decoders in it are small RISC processors... that's exactly the case here: Modern CISC's *do* use a lot of RISC-type architecture to run as fast as possible. Does this suggest, perhaps, that RISC has speed advantages over CISC? No, of course it doesn't!.
I think you miss the point of what the author want to point out here. He only want to point out that "RISC is here to stay and CISC will die" theory isn't true. Maybe the RISC is fast, but CISC chips had already have their ways of matching RISC speed and efficiency. After all, the author already pointed out that all enginners come from the same uni/college and learn the same books, maybe the same one as what you've learned. I a computer engineering grad from UPM in Malaysia, and my lecturers also kinda say the same thing to me. But in IT world, everything changed quickly and the not everything you've learned in university today will apply to then outside world in one or two years.
Aaaah!!
The posts in this topic are honestly getting longer and longer. But honestly speaking, I wonder if it's worth actually posting anything to reply to cHiBiMaRuKo cause he doesn't seem to read what we say.
quote from http://www.g256.com" TARGET=_blank>www.g256.com today
_________________________________________MS to lose $2bn on Xbox
--------------------------------------------------------------------------------
Icenum Thursday March 8, 2001 3:04 AM Your Time
The Register has some darn interesting insight on MS and the XBox, good for consumers and bad for MS..Awwwww:
Merrill Lynch has come to the shock conclusion that Microsoft is going to lose a lot of money on Xbox. The console could drain up to $2 billion from the Beast of Redmond's coffers before break-even.
As the world+dog knows, consoles are sold at a loss in the early days, as manufacturers subsidise the low price points needed to drive sales of the machine.
Microsoft has yet to announce Xbox pricing, but most observers put it at around $250. Merrill Lynch reckons each console will cost around $375 to produce - simple maths tells you Microsoft is flushing $125 down the pan. The figure might be higher or lower depending on what Microsoft ultimatly asks punters to pay. The Xbox price tag isn't expected to be much higher than the $299 Sony currently charges for the PlayStation 2.
_________________________________________
You obviously don't get my point up there. Did I say that Microsoft will make money from X-Box sales? No! Microsoft will highly likely also take the strategy employed by Sony ( if you did know how Sony operates on the console market ). Did you think that PS2 really cost ONLY US 300? Maybe I should have make my point clearly next time.
[This message has been edited by cHiBiMaRuKo (edited March 08, 2001).]
