Linked by Thom Holwerda on Tue 9th Sep 2008 08:52 UTC
Thread beginning with comment 329874
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: Intel is not scared
by dmantione on Wed 10th Sep 2008 18:48
in reply to "RE[7]: Intel is not scared"
Which is the whole point of the design. Have a small number of primitive instructions, and use those to build up and make more high level ones. That is the whole point of the RISC design; keep it simple and highly optimised, and use those as building blocks for more complex things.
Correct, that was the plan, it just didn't work that way. We are running against GHz limits, it simply isn't feasible to build an 8 GHz MIPS to compete with a 3 GHz x86.
You are turning this into a RISC v.s. CISC discussion, but it's not. This applies to MIPS and MIPS only. There is much less fundamentalism in other RISC architectures. PowerPC can do base+index+offset addressing. ARM has base+index+barrelshifter.
The reason why MIPS is so cripled has also nothing to do with it being RISC. The real reason is that the designers of the MIPS wanted to do a deeply pipelined design, MIPS was all about clock speed. By focussing on 5 stage pipeline, the MIPS designers were quite a bit ahead. Unfortunately, they ran out of die space. They had to cut features, and so they did. They removed instructions (the first MIPS did need a coprocessor to multiply & divide) and they cut logic from the addressing modes.
With todays multi-billion transistor chips, a barrel shifter and base/index/offset adder consume next to nothing in die space. As the benefit is huge, there is no reason they shouldn't be on a modern chip.
And hey, this is what happened. x86 has them, ARM has them, PowerPC has no barrel shifter but does have the base/index/offset. MIPS is more an exception than x86 is.
Now, that might be an issue with a crappy compiler which has not been written from the ground up with that paradigm in mind. The reality is that if a compiler were to be designed solely to compile software for that processor alone - and thus not have to be compromised for the sake of supporting other processors, I don't see how it could be a failure.
GCC, for example, is primarily designed for portability. The binaries produced by GCC is ugly at the best of times, and given that the x86 processors are pretty much happy to chew through any crap you throw at it - a crappy compiler isn't going to severely hamper performance to such a degree that a poorly written compiler would with a strictly RISC based processor.
GCC, for example, is primarily designed for portability. The binaries produced by GCC is ugly at the best of times, and given that the x86 processors are pretty much happy to chew through any crap you throw at it - a crappy compiler isn't going to severely hamper performance to such a degree that a poorly written compiler would with a strictly RISC based processor.
This has nothing to do with compilers. I am co-author of Free Pascal, so let me speak with authority. MIPS is a piece of cake to design a compiler for, because it has a large register file, orthogonal instruction set, well defined calling conventions. Compared with that, x86 is hell with its low register count, the stacks of weird instructions, instructions that only work on specific registers and many different calling conventions in use.
I have no experience with GCC's MIPS code generation, but I'm not impressed with GCC's x86 code generation.
I don't know what the hell you've been smoking - the first gigahertz processor put out was the AMD Athlon - back when they were using the old slot A design for their processors. They were the first to bring gigahertz to the desktop. Intel was only fractionally behind it. The difference between gigahertz to gigahertz only really started to be noticeable when the P4 was launched and the older PIII processors when clocked at 1.3Ghz were beating the P4 clocked at 1.7Ghz.
Let me repeat: a 600MHz Duron blew the 1GHz Pentium III into pieces in many (most?) benchmarks. Especially the Athlon x87 FPU was really fast. Correct, AMD had the first gigahertz processor, did I state something that did suggest otherwise?
Edited 2008-09-10 18:53 UTC






Member since:
2005-07-06
Which is the whole point of the design. Have a small number of primitive instructions, and use those to build up and make more high level ones. That is the whole point of the RISC design; keep it simple and highly optimised, and use those as building blocks for more complex things.
Now, that might be an issue with a crappy compiler which has not been written from the ground up with that paradigm in mind. The reality is that if a compiler were to be designed solely to compile software for that processor alone - and thus not have to be compromised for the sake of supporting other processors, I don't see how it could be a failure.
GCC, for example, is primarily designed for portability. The binaries produced by GCC is ugly at the best of times, and given that the x86 processors are pretty much happy to chew through any crap you throw at it - a crappy compiler isn't going to severely hamper performance to such a degree that a poorly written compiler would with a strictly RISC based processor.
I don't know what the hell you've been smoking - the first gigahertz processor put out was the AMD Athlon - back when they were using the old slot A design for their processors. They were the first to bring gigahertz to the desktop. Intel was only fractionally behind it. The difference between gigahertz to gigahertz only really started to be noticeable when the P4 was launched and the older PIII processors when clocked at 1.3Ghz were beating the P4 clocked at 1.7Ghz.
Edited 2008-09-10 06:58 UTC