Messages in this thread | | | From | doctor@fruitbat ... | Subject | Re: Intel microcode fixes [OFF-TOPIC] | Date | Sat, 21 Nov 1998 22:58:11 -0800 (PST) |
| |
ralf@uni-koblenz.de stated ... > > On Thu, Nov 19, 1998 at 02:09:07PM -0800, doctor@fruitbat.org wrote: > > > Why? This technology has existed on mainframes for years. The really > > neat aspect to this is that you can design your own instructions! > > Microprocessors today are getting so complex that they start to take on > > some of the attributes of mainframe processors. Why not an upgradable > > processor? Think of how the Intel Floating Point Bug would have been a > > non-issue if Pentiums were microcode upgradable? Why not extent the idea > > and have a general-purpose micro-processor archtecture which you can > > upload whichever instruction set you wished? Say you feel like running > > 68040 based software today? A quick Zap and your set! Hey, how about > > running some of those old Apple ][ programs? Granted there are other > > issues (bus access, interrupts, etc) which would have to be hammered out, > > but the potential is incredible! > > Microcode upgrade are not a perfect solution for everything. In those > CPUs that still use microcode it's role is getting less and less important. > Simple example, old CPUs had multiply instructions implemented as you would > have done it on for example a 6502 in software. Newer designs came up > with special microinstructions supporting multiplies by 32 x 2 bit multiplies > for example and that microinstructions were used to implement the multiply > instruction. Some RISCs have such instructions as well. Finally, the entire > multiplier was put into hardware, microcode completly gone away.
I'm quite aware of the evolution of processor architecture and implementation and agree that the trend has been to move away from microcoded instructions toward hardwired instructions. But to any kind of the speed out of it you have to add super-pipelines, complex instruction interleaving and register management and a large cache to account for the fact that your instruction flow is now about 3 times larger than before. Suddenly your "lets get small" paradigm has balooned into a very large and hungry beast. As a side "benefit", your compiler has to be smarter about the ordering of the instructions it generates. Don't get me wrong, all this makes for a more optimal execution flow, time wise, but the volume of code you must generate keeps expanding, thus requiring more cache, more main memory and more disk space. This might be great for the memory and disk industry, but for the poor consumer, it means replacing your machine every 3 years (or is it 2 now...progress and all that ;-)
> See the pattern? Microcode was always used to fill the gap where silicon > was for some reason not the solution, be it complexity of design, correctness > or whatever issues. Microcode was used to provide an outer shell around a > changing implementation.
I see the pattern, alright, and I'm not impressed with it. I believe that smaller is better, but having to use many itty-bitty instructions to construct the equivalent of a higher level construct is like having to build a house with sand, one grain at a time.
> Your idea is completly orthogonal to the RISC idea, it's putting complex, > rarely used things into silicon, not software where they should go.
Well, I've been called worst ;-) The whole issue of RISC versus CISC has been hashed out, time and time again, in comp.arch. I suggest we all drop this thread to let linux-kernel mail have the bandwidth.
> Ralf >
-- Peter A. Castro (doctor@fruitbat.org) or (pcastro@us.oracle.com)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |