Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 v7 ucbtopaz-1.8; site ucbtopaz.CC.Berkeley.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!ucbvax!ucbtopaz!mwm
From: mwm@ucbtopaz.CC.Berkeley.ARPA
Newsgroups: net.micro
Subject: Re: Need a microprogramming consultant!
Message-ID: <784@ucbtopaz.CC.Berkeley.ARPA>
Date: Mon, 4-Mar-85 04:44:08 EST
Article-I.D.: ucbtopaz.784
Posted: Mon Mar  4 04:44:08 1985
Date-Received: Wed, 6-Mar-85 03:40:50 EST
References: <1272@drux3.UUCP>
Reply-To: mwm@ucbtopaz.UUCP (Praiser of Bob)
Organization: Missionaria Phonibalonica
Lines: 82
Summary: 

In article <1272@drux3.UUCP> mmt@drux3.UUCP (ThomasMM) writes:
>I am not a very hardware oriented.  Could someone give
>me an explanation (in simple terms) of how microprogramming
>works?????    Reply either via mail to ihnp4!drux3!mmt
>or via the net.  Thank you.

Since someone else asked for the reply to go to the net, I'll give
everybody a chance to correct me.

First, I'm going to assume that you meant "writing microcode for a
processor" rather than "programming a microprocessor" when you said
microprogramming. If I'm wrong, stop reading here.

Recently (like the last decade or so), people have discovered that building
a "two-level" machine buys you various things. The idea is that instead of
building hardware that interprets the machine instructions that are your
target directly (this is the macromachine), you build hardware that
interprets a simpler machines instruction set directly (this is the
micromachine), then write an interpreter for the target macromachine that
runs on the micromachine.

The things this approach buys you include faster development time, cheaper
development, easier "hardware" fixes, easier inter-machine compatibility,
and probably others I've missed. The cost is that the microcoded processor
is slower than a hardwired machine.

To help with the loss of speed, most microcoded machines put in a small
amount of high-speed memory, and store the microcode in that. This is
usually referred to as the "control store" (CS).  On some machines, you get
a "Writeable Control Store," or WCS.

Examples: Almost any modern machine, but I'm going to pick on the IBM 370
line. The entire line was microcoded. Most (all?) of the machine had
different hardwired machines underneath them, but the line had identical
macro instruction sets. Estimates on how much slower this made user code
run go up to 1000% percent, but the low end 370's used standard user memory
for control store. There was enough speed loss at the high end that Amdahl
did fairly well selling hardwired 370 clones that ran faster and cost less.
IBM used the microcode capability to fight this, by releasing OS's that
required concurrent microcode changes to add new instructions.

Obviously, if you can run your code as microcode, then it will run faster
than if you run it as machine code. On a modern machine it will get the
benefit of the fast memory, no instruction fetches to the machine memory,
and not having to pass through instruction decoding. If you've got a
machine with a WCS, you can create your own instruction that do whatever
you'd like them to do. This is the kind of thing normal mortals do when
they are "microprogramming" a machine.

Examples for this kind of thing include putting butterfly FFT's in
microcode, obscure table lookups, and block move instructions.  Burroughs
sells machines which have "what microcode" indicators in the process data
structure, and you swap in that process's microcode when you run the
process.  The BBN C/70 goes even farther, and includes a C compiler for
microcode.  You tell the linker, and it builds "subroutine linkage" that
amounts to a new instruction to call your microcode routine.

The difficulty of writing your own microcode depends on the micromachine in
question. Micromachines come in two basic flavors: vertical and horizontal.
Vertical micromachines look like simple conventional machines. For example,
writing for the WCS-11 module on the 11/03 is about like writing for an
8080, except for subroutine linkage.

Horizontal micromachines have nice long words (in the hundreds of bits),
with bits to open/redirect gates, and other such nitty-gritty. There tends
to be obscure timing constraints, and other things you'd rather not have to
worry about.  You can't get closer to the machine without a soldering iron.
Since this lets you use the inherent parallelism in the hardware, it can
result in very fast code. It also gives me headaches.

As esoterica, it might be noted that some machines have three such levels:
a macro machine that the users get to see, a micro machine that microcoders
write for, and a nanomachine that truly crazy people write for. The
Nanodata QM-1 does this, and I've heard rumors that the 68K chips have
three levels.

There is an ACM Computing Surveys on microprogramming that includes an
excellent introduction to the topic. My copy is buried in one of a large
number of boxes. If you'd like the reference, send mail. Or maybe some kind
soul will post it.