Microcode examples
Zvi Lamm
Complicated CPU instruction sets are sometimes built on top of a simpler,
more constant microcode layer (for example on IBM mainframes, updating
the OS ocasionally requires loading new microcode).
Does any one have examples, or online references to microcode instruction
sets, and code?
I seem to recall many ancient stories about mere mortal programmers
playing with microcde. Is this possible on modern CPUs, or is the
microcode burned?
Any info on these things is welcome.
TIA,
--
Ehud Lamm msl...@pluto.mscc.huji.ac.il
Bob Supnik
In article <4v4cf7$7...@news.huji.ac.il>, msl...@pluto.mscc.huji.ac.il says...
>
>Complicated CPU instruction sets are sometimes built on top of a simpler,
>more constant microcode layer (for example on IBM mainframes, updating
>the OS ocasionally requires loading new microcode).
>
>Does any one have examples, or online references to microcode instruction
>sets, and code?
>
>I seem to recall many ancient stories about mere mortal programmers
>playing with microcde. Is this possible on modern CPUs, or is the
>microcode burned?
>
every PDP-11 (except the 11/20), every VAX, every 68XXX, and most x86's were
microcoded.
In non-microprocessor implementations, the control store (the microcode memory)
was sometimes implemented or supplemented by fast RAM memory and thus could be
either changed completely or modified (usually for patching purposes). In a
few cases this capability was made available to users. Examples included the
PDP-11/60 and the LSI-11. The 11/60's writeable control store was used to
implement a PDP-8 simulator that was faster than any existing PDP-8 system.
More often, the capability was used internally. In the early days of the Alpha
program, a VAX 8800's microcode was altered to introduce out of order memory
references, in order to test the impact this would have on operating systems.
A patch store to a ROM based microprogram is implemented in a few
microprocessors, notably V-11 (a multichip VAX) and NVAX (the last VAX
microprocessor). The V-11 patch store was used to implement a non-intrusive
multimode tracing capability.
Microcode instruction sets are sometimes described in architectural articles on
implementations; see for example the issues of the Digital Technical Journal
(which is online) describing MicroVAX, CVAX, Rigel, NVAX. I don't know of any
published microcode listings, at least not for modern systems. You could check
via an Internet search engine like AltaVista (plug).
/Bob Supnik
/Digital Equipment Corporation ex-microcoder
Konstantin Olchanski
In article <4v4cf7$7...@news.huji.ac.il>, msl...@pluto.mscc.huji.ac.il (Zvi Lamm) writes:
> Complicated CPU instruction sets are sometimes built on top of a simpler,
> more constant microcode layer (for example on IBM mainframes, updating
> the OS ocasionally requires loading new microcode).
>
> Does any one have examples, or online references to microcode instruction
> sets, and code?
You may try to look at the AMD 2901 4-bit-sliced chip series. They contain
a 4-bit ALU, 32 (or 16?) 4-bit registers, etc... The AMD
documentation contains the microcode instruction sets.
By ganging 8 of them together you can build a 32 bit CPU (ours are
microcoded to look like IBM 360 CPUs running with a 10 ns cycle),
by using 4 of them you get a 16-bit CPU and you can microcode it
to look like a PDP-11 CPU (some of the Russian-build PDP-11
machines had CPUs assembled from the Russian-cloned 2901 parts).
> I seem to recall many ancient stories about mere mortal programmers
> playing with microcde. Is this possible on modern CPUs, or is the
> microcode burned?
What you want is called "writable control store".
Otherwise, there is nothing magic about microcode. It is like writing
in normal assembly, except that the resulting code runs faster.
These days, I presume it would not be hard to modify GCC to
emit let's say, 2901 microcode, and program these beasts
directly in C :-)
C.O.
Walter Banks
> Complicated CPU instruction sets are sometimes built on top of a simpler,
> more constant microcode layer (for example on IBM mainframes, updating
> the OS ocasionally requires loading new microcode).
There are two kind of microcode controlled CPU's. Vertical where each of
the instructs looks like a conventional instruction. It is executed with
the traditional fetch decode execute sequences. Horizontal microcode
has a wide instruction that has individual bits connected to specific
control lines of the underlying data manipulation hardware. The best way
to descibe this from of microcode is a finite state machine. Some
versions of this have a field to define where the next "horizontal
instruction" will come from.
The Vertically coded microcode can use conventional software tools,
(assembles and compiler) to generate the code. Development
tools for horizontially coded microcode are more complicated to develop.
Horizontial micrcode can be designed to be very fast at a cost in ROM
size.
Walter Banks
http://www.bytecraft.com
Michael Bellman
Konstantin Olchanski wrote:
>
> In article <4v4cf7$7...@news.huji.ac.il>, msl...@pluto.mscc.huji.ac.il (Zvi Lamm) writes:
> > more constant microcode layer (for example on IBM mainframes, updating
> > the OS ocasionally requires loading new microcode).
> >
> > sets, and code?
>
> You may try to look at the AMD 2901 4-bit-sliced chip series. They contain
> a 4-bit ALU, 32 (or 16?) 4-bit registers, etc... The AMD
> documentation contains the microcode instruction sets.
>
> By ganging 8 of them together you can build a 32 bit CPU (ours are
> microcoded to look like IBM 360 CPUs running with a 10 ns cycle),
> by using 4 of them you get a 16-bit CPU and you can microcode it
> to look like a PDP-11 CPU (some of the Russian-build PDP-11
> machines had CPUs assembled from the Russian-cloned 2901 parts).
>
> > I seem to recall many ancient stories about mere mortal programmers
> > playing with microcde. Is this possible on modern CPUs, or is the
> > microcode burned?
>
> What you want is called "writable control store".
>
> Otherwise, there is nothing magic about microcode. It is like writing
> in normal assembly, except that the resulting code runs faster.
> These days, I presume it would not be hard to modify GCC to
> emit let's say, 2901 microcode, and program these beasts
> directly in C :-)
>
> C.O.
One of the latest bullshitting concerning microcoding was successfully
implemented by NexGen in their line of Nx586 CPUs, where the x86
instruction set was implemented in the microcode, called RISC86. And
they (NexGen) promised to open this option for programmers (just using
one instruction to turn ON/OFF the internal microcode core, responsible
for x86 instr. set interpretation. Unfortunately, NexGen is the property
of AMD, and (as far as I know) AMD plans to stop this line of
bullshitting.
My idea was to buy one Nx-based M/B and to emulate in RISC86 code the
JVM. I know what some people in Moscow try to activate similar project,
but not for such stupid aim as Java processor. May be, for
Gamma-processors... ?
M.Bellman, Jerusalem, Israel, mi...@fh.huji.ac.il
M. C. Ertem
Konstantin Olchanski (olch...@a2.phy.bnl.gov) wrote:
: You may try to look at the AMD 2901 4-bit-sliced chip series. They contain
: a 4-bit ALU, 32 (or 16?) 4-bit registers, etc... The AMD
: documentation contains the microcode instruction sets.
Also, there was a book out by 'Mick & Brick' if I remember right. Then
again, this was way back when... (Early 80's)
MCE
NOTE: I call 800 and local numbers in any junk e-mail I get.
So there! Don't send me any unsolicited e-mail selling stuff.