Messages in this thread | | | Date | Sat, 21 Nov 1998 01:13:11 +0100 | From | ralf@uni-kobl ... | Subject | Re: Intel microcode fixes [OFF-TOPIC] |
| |
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.
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.
Your idea is completly orthogonal to the RISC idea, it's putting complex, rarely used things into silicon, not software where they should go.
Ralf
- 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/
| |