Re: Intel microcode fixes [OFF-TOPIC]

doctor@fruitbat.org
Thu, 19 Nov 1998 14:09:07 -0800 (PST)


H. Peter Anvin wrote ...
>
> Followup to: <3650AC6B.982F73D@mindless.com>
> By author: menion <menion@mindless.com>
> In newsgroup: linux.dev.kernel
> > >
> > > Microcode fixes for Intel P6-core chips are uploaded to the CPU either
> > > by the BIOS, or by a driver. Linux obviously doesn't have a driver,
> > > which means it has to be done by the BIOS (usually shipped as part of
> > > the BIOS) or we have to get a driver.
> > >
> > > The microcode update itself is delivered from Intel as a binary blob.
> > >
> > > -hpa
> >
> > Call me superstitous (and a bad speller), but the idea of upgrading
> > micro-code is even worse than that of bioses. Frankly the idea of
> > replaceing a bios is enough to make me reach for a little Maalox (at
> > times), but the idea of upgrading _micro-coding_ on a stinking CPU makes
> > me want... some Mez-Cal(*), or Jose Cuervo at least. (and lots of it.)

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!

> The microcode update is nonpersistent. If it doesn't work, you can
> cut the power and restart the CPU in original state.

Too bad. Having it be persistent would be better, with a way of
resetting to factory defaults.

> -hpa

-- 
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/