Message-ID: <1272@drux3.UUCP>
Date: Fri, 1-Mar-85 12:25:33 EST
Article-I.D.: drux3.1272
Posted: Fri Mar  1 12:25:33 1985
Date-Received: Sat, 2-Mar-85 04:41:56 EST
Organization: AT&T Information Systems Laboratories, Denver
Lines: 4

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.

Message-ID: <501@ahuta.UUCP>
Date: Fri, 1-Mar-85 13:57:41 EST
Article-I.D.: ahuta.501
Posted: Fri Mar  1 13:57:41 1985
Date-Received: Sat, 2-Mar-85 04:47:45 EST
References: <1272@drux3.UUCP>
Organization: AT&T Information Systems Labs, Holmdel NJ
Lines: 3

REFERENCES:  <1272@drux3.UUCP>

It would be great to see the answer in the net.

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.

	  

		
		
		
Report message to a moderator

Message-ID: <807@ecsvax.UUCP>
Date: Mon, 4-Mar-85 17:20:47 EST
Article-I.D.: ecsvax.807
Posted: Mon Mar  4 17:20:47 1985
Date-Received: Wed, 6-Mar-85 04:19:39 EST
References: <784@ucbtopaz.CC.Berkeley.ARPA>
Organization: NC State Univ.
Lines: 5

A reference which goes into much more detail is "An Intro to
Microcomputers by Adam Osborne, Vol.1 Basic Concepts".  It has
much of a chapter on microprogramming with very easy to follow
examples, and you don't have to know engineering to follow it.
--henry schaffer

Message-ID: <504@ima.UUCP>
Date: Tue, 5-Mar-85 23:37:39 EST
Article-I.D.: ima.504
Posted: Tue Mar  5 23:37:39 1985
Date-Received: Fri, 8-Mar-85 03:53:44 EST
Lines: 17
Nf-ID: #R:drux3:-127200:ima:11700011:000:993
Nf-From: ima!johnl    Mar  5 21:42:00 1985

I wish we saw more stuff here like the note from ucbtopaz!mwm on 
microprogramming.  Clear and to the point.  But I can't resist a few niggles.  

One thing to keep in mind is that microprogramming is a mixed blessing.  There 
is an increasingly popular school of thought that states that the slowdown 
from interpreting microcode isn't worth it, and you'd be better off making a 
very simple machine that executes instructions directly, and depending on your 
compiler to generate code for it.  The Berkeley RISC is one of the best known 
of the efforts to do this.  Microcoding made more sense when ROMs (where 
microcode usually lives) was much faster than RAMs (where regular programs 
live.) These days, in most systems they're about the same speed, which negates 
much of the speed people used to hope for from microcode.  

Finally, it turns out that microprogramming is far from a new idea.  It was 
originally proposed for an early British machine in 1952!  

John Levine, ima!johnl 

Message-ID: <106@ixn5f.UUCP>
Date: Thu, 7-Mar-85 14:24:51 EST
Article-I.D.: ixn5f.106
Posted: Thu Mar  7 14:24:51 1985
Date-Received: Fri, 8-Mar-85 05:15:06 EST
References: <501@ahuta.UUCP>
Organization: AT&T Bell Labs, Naperville, Il
Lines: 1

Got a couple of free months?

Message-ID: <5191@utzoo.UUCP>
Date: Fri, 8-Mar-85 13:50:15 EST
Article-I.D.: utzoo.5191
Posted: Fri Mar  8 13:50:15 1985
Date-Received: Fri, 8-Mar-85 13:50:15 EST
References: <504@ima.UUCP>
Organization: U of Toronto Zoology
Lines: 14

> Finally, it turns out that microprogramming is far from a new idea.  It was 
> originally proposed for an early British machine in 1952!  

Actually, the concept of microprogramming goes back much further than
that, although it was forgotten for a long time and then re-invented
by Maurice Wilkes in 1952.  Some of Charles Babbage's drawings for
his never-built Analytical Engine show what is clearly, in modern
terminology, microprogrammed control for a specialized execution unit.
But Babbage never published much about the general principles of his
designs, and nobody noticed this particular invention until quite
recently.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

Message-ID: <184@redwood.UUCP>
Date: Tue, 5-Mar-85 03:35:30 EST
Article-I.D.: redwood.184
Posted: Tue Mar  5 03:35:30 1985
Date-Received: Sat, 9-Mar-85 08:47:58 EST
References: <1272@drux3.UUCP> <501@ahuta.UUCP>
Organization: [Consultant], Foster City, CA
Lines: 109

+---------------
| REFERENCES:  <1272@drux3.UUCP>
| It would be great to see the answer in the net.
+---------------
O.k., this is what I mailed to original poster (edited slightly):
==========================================================================

In-reply-to: your article <1272@drux3.UUCP>
+---------------
| 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.
+---------------

Well, for starters, you haven't said enough for me to know what your
problem is.  I assume you are talking about microprogramming as used
in the design of the instruction set of a computer, or in the design
of the data paths of some peripheral controller.

Most commonly, "microprogramming" is a term used to describe the design
of a hardware finite-state machine which was constructed with it's
state-transition matrix in a ROM. (Are you familiar with "finite
state machines"?) The contents of the ROM are the "micro-program".
Generally, there are a certain number of input variables (logic
levels) that can be tested, and which can cause state changes
(micro-code "branches"), and a certain number of output variables
(logic levels) which can be set, depending on the current state.

Inputs might be levels such as "The ALU Output Value Is Positive", or
"DMA Bus Request 4", or "Memory Data Bus Bit 15". Outputs might be such
as "Clear Timing Flip-Flop 27", or "Enable The Contents Of Memory
Address Register Onto The Memory Address Bus". (Hardware engineers
often shorten names like the latter to cryptic forms like "MAR2MAEN"...
or worse. ;-} )

In the most general case, the input vector is concatenated with the
state vector, and used to look up in the ROM the pair "new-state-vector"
and "new-output-vector". The "new-state-vector" is saved as the (now
current) state vector, and the "new-output-vector" is sent to the
various outputs. (Is this all too abstract for you?)

"Micro-programming" is the process of selecting those ROM contents,
and bears a faint resemblance to ordinary (macro-) programming.

Large state machines are easier (thus cheaper) to design using micro-
programming than are state machines built of random (or discrete)
logic gates, but because of its complexity, it still is expensive
to design a microprogram. (The logical conclusion is: "Large state
machines are expensive".) The resulting "micro-programmed machines"
are also usually cheaper to manufacture than discrete machines,
though sometimes they suffer in operating speed.

There are many simplifications, complications, and variations to the
general case to save space in ROM, to save other hardware, and to simplify
design ("programming"). Sometimes there is an explicit "micro-PC" (uPC)
which stores the current state vector; sometimes the state vector is
implicit in the value of some output variable(s). Sometimes the uPC can
be incremented and the incremented value used as the "next state" unless
explicitly overridden (allowing next-state bits in the ROM to be used
for other purposes except when explicitly needed); sometimes each micro-
instruction (word in the ROM) carries with it the next PC (ROM address).

Sometimes some of the outputs (from a previous state) are used to select
a subset of the inputs to be looked at (this reduces the size of the ROM,
since not all possible combinations of "state|input" are needed). Sometimes
only certain bits of the uPC are affected ("loaded", or "jammed") by the
results of a test.

Some micro-ROMs have one bit for every possible output wire or control
lead needed; such machines are said to use "horizontal microcoding".
Sometimes there is a coded field in the uROM which is decoded externally
to select which ONE of several outputs will be activated; such machines
are "vertically microcoded". Vertically-coded machines may also take
several steps in succession to do what a "horizontal" machine could
do in one step; conversely, vertically machines are usually cheaper,
because they use less ROM, and fast uROM is expensive. 

The range of variations is immense.  So... there is not very much one
can say further without relating it to a specific situation or hardware
design problem. Oops! There IS one other little thing: Sometimes when
microprogramming is used to design a system (such as a large computer),
the designers choose to store the microcode in RAM, rather than ROM.
(Obviously, it has to be loaded into RAM from "somewhere" when the
machine is first powered up. Usually "somewhere" is a smaller computer
which has ITS microcode in ROM, and which reads the large machine's
microcode from a disk file.) This means that the low-level function
of the machine can be changed if needed (say, to fix a design error or
defect) without being re-wired or without replacing (expensive) ROM
chips. This has allowed hardware engineers to get nearly as sloppy as
software people, so that one now routinely hears "Well, that bug is
fixed in the next release of the microcode".  ;-} ;-}

Note: Several semiconductor manufacturers make special chips that help
one to design/build microprogrammed logic systems. The "2900" series
chips (made first by AMD but now multiply-sourced) are quite popular
for microprogrammed machines. The applications notes for the 2911
sequencer (a uPC with extra goodies in it) will give more examples of
how microprogramming is used. I believe there is an AMD app note that
even gives a complete diagram for a disk controller, including the
table of micro-ROM contents. Ask your local hardware wizard.


Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	510 Trinidad Lane, Foster City, CA  94404

Message-ID: <8942@brl-tgr.ARPA>
Date: Tue, 5-Mar-85 08:23:34 EST
Article-I.D.: brl-tgr.8942
Posted: Tue Mar  5 08:23:34 1985
Date-Received: Sat, 9-Mar-85 09:11:51 EST
Sender: news@brl-tgr.ARPA
Lines: 17

GIGO

As I understand it, Micro-programming is the series of operations that occur
within the microprocessor for placing data and address information on busses,
 or routing data to the Arithmetic logic unit; again within the micro itself.

For many processors, this micro-code is burned in and unchangeable.  But for 
some, the processor looks outside the chip for it's micro-code.  

Micro-programming provides a plethora of architectural techniques such as 
Pipelining which speed up throughput.


Hope that helps a little.

                                  Ron Kushnier
                                  kushnier@nadc.arpa

Message-ID: <8917@brl-tgr.ARPA>
Date: Mon, 4-Mar-85 14:36:43 EST
Article-I.D.: brl-tgr.8917
Posted: Mon Mar  4 14:36:43 1985
Date-Received: Sat, 9-Mar-85 11:57:49 EST
Sender: news@brl-tgr.ARPA
Lines: 46

A microprogrammable CPU is one in which control points within the CPU
are directly controlled by bits in the instruction word.  For example,
in a simple machine with two registers (e.g., A and B) connected by a bus,
there would be a control bit (e.g., bit 3) in the instruction to gate register
A onto the bus, another (bit 2) to gate register B onto the bus, a third
(bit 1) to load register A from the bus and a fourth (bit 0)to load
register B from the bus.  So, to load register A from register B, the
instruction would be 0110.

Now, extend this to cover ALL the control points in a CPU - and give
each one a separate bit in each instruction, and you have a horizontally
microprogrammed CPU.  But, the information in the instructions will
be very sparse (i.e., there will be only a few control points turned on
in each instruction).  So, encode all the control points in binary and
allow only one control point per instruction, and you have a vertically
microprogrammed CPU.  In practice, groups of mutually exclusive control
points (in the above example, you really only want to gate either A or
B onto the bus, but not both), are encoded in fields in the
microinstruction, resulting in an architecture somewhere between
vertical and horizontal microcode.

How is microprogramming used?  Microprogram storage is typically
(although not always) fast and small.  The usual practice is to code
an emulator in microcode which executes a more "normal" instruction
set.  This instruction set may be patterned after an existing machine
(allowing capture of existing software) or after a more "ideal"
hypothetical machine (e.g. a pure stack-oriented architecture).

For more detailed descriptions, see:

Katzan, Harry. "Microprogramming Primer". McGraw-Hill Computer Science
Series (1977).

Mano, M. Morris. "Computer System Architecture" (ch. 7-9).
Prentice-Hall, Inc. (1976).

					- Ralph

Ralph Droms					ihnp4!purdue!droms
445 MATH					droms@purdue.arpa
Dept. of Computer Science			droms@purdue.csnet
Purdue University
West Lafayette, IN 47906


----------

Message-ID: <1820@sdcrdcf.UUCP>
Date: Wed, 6-Mar-85 13:32:11 EST
Article-I.D.: sdcrdcf.1820
Posted: Wed Mar  6 13:32:11 1985
Date-Received: Sun, 10-Mar-85 05:15:18 EST
References: <1272@drux3.UUCP> <501@ahuta.UUCP> <184@redwood.UUCP>
Reply-To: darrelj@sdcrdcf.UUCP (Darrel VanBuer)
Organization: System Development Corp. R+D, Santa Monica
Lines: 23
Summary: 

Another reason to have microprograms in RAM (besides reducing cost of bug
fixes) used by a number of companies (notably those making Lisp machines) is
tailoring the instruction set of the machine to the application E.g. the
Xerox Dolphin can be an Alto, a Lisp machine, a Smalltalk machine or a Mesa
machine, depending on which microcode is (dynamically) loaded.  The Alto
code is straight emulation to exploit a preexisting operating system, the
others implement an abstract machine model tailored to the language.
The Dolphin has only a single processor, but has a small read-only
microprogram memory which contains just enough to bootstrap microcode from
the disk or Ethernet.
Some computers and vendors provide tools for user microcode (usually for
augmenting the instruction set rather than replacing it), a few even
implement virtual memory microstores!

-- 
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
                                                            !sdcrdcf!darrelj
VANBUER@USC-ECL.ARPA

Message-ID: <802@ucbtopaz.CC.Berkeley.ARPA>
Date: Thu, 7-Mar-85 22:51:46 EST
Article-I.D.: ucbtopaz.802
Posted: Thu Mar  7 22:51:46 1985
Date-Received: Sun, 10-Mar-85 07:07:13 EST
References: <504@ima.UUCP>
Reply-To: mwm@ucbtopaz.UUCP (Praiser of Bob)
Organization: Missionaria Phonibalonica
Lines: 36
Summary: 

In article <504@ima.UUCP> johnl@ima.UUCP writes:
>I wish we saw more stuff here like the note from ucbtopaz!mwm on 
>microprogramming.  Clear and to the point.  But I can't resist a few niggles.

Thank you.

>One thing to keep in mind is that microprogramming is a mixed blessing.  There
>is an increasingly popular school of thought that states that the slowdown 
>from interpreting microcode isn't worth it, and you'd be better off making a 
>very simple machine that executes instructions directly, and depending on your
>compiler to generate code for it.  The Berkeley RISC is one of the best known 
>of the efforts to do this.

Note that (some of) the people selling RISC machines (pyramid) are *still*
using microcoded machines. The simpler target instruction set means you
need less rom for microcode, and less "magic" hardware - a compromise
between pure RISC and CISC (complex ...). In exchange for the
interpretation time, you get more flexibility in the machine with less
trouble. For instance, pyramid changed from word-aligned word fetches to
unaligned word fetches by tweaking the microcode. Like any complex decision,
you have to make some trade-offs.

>Finally, it turns out that microprogramming is far from a new idea.  It was 
>originally proposed for an early British machine in 1952!  

Not surpising. Most of the good "new" ideas in CS are rather old. Could you
supply a reference so I can read about it?

BTW, redwood!rpw3 posted a very detailed description of one form of
vertical microcode; as it appears in I/O devices, etc. He also mentions
bit-sliced machines (the AMD 2900), which make for fast design of fast
custom hardware (like Wirth's Lilith). The reference for such is "Bit-slice
Microprocessor Design" by Mick and Brick (no, I'm not kidding), from
McGraw-Hill.

	  

		
		
		
Report message to a moderator

Article-I.D.: redwood.188
Posted: Mon Mar 11 06:25:06 1985
Date-Received: Thu, 14-Mar-85 03:41:37 EST
References: <504@ima.UUCP> <802@ucbtopaz.CC.Berkeley.ARPA>
Organization: [Consultant], Foster City, CA
Lines: 51

+---------------
| >Finally, it turns out that microprogramming is far from a new idea.  It was 
| >originally proposed for an early British machine in 1952!  
| Not surpising. Most of the good "new" ideas in CS are rather old. Could you
| supply a reference so I can read about it?
+---------------

Try 1951. The paper (actually, speech) which is generally agreed to have
started it all is:

	Wilkes, Maurice V., "The best way to design an automatic
	calculation machine", Manchester University Computer
	Inaugural Conference, (July 1951), pp. 16-18

All you want to know about early microprogramming (and more than you will
EVER want to know about microprogramming in the IBM System/360 Model 40, the
IBM 360/50, the RCA Spectra 70/45, and the Honeywell H4200) can be found in
the text "Microprogramming: Principles and Practices" by Samir S. Husson
(Prentice-Hall 1970) [which is where I found the above reference].

In a historical aside, Husson notes [p.25]:

	"It is believed that Wilkes introduced the term 'microprogramming'
	with its present meaning. However, the Lincoln Laboratory [at MIT]
	used it prior to 1950 to describe a system in which the individual
	bits in an instruction directly control gates in the processor."

Those who remember the DEC PDP-8 (which owes much to the LINC processor)
will recall this earlier meaning as applies to the PDP-8's OPR instructions
and the IOT instruction. (You can build up a complex instruction by taking a
basic instruction class and turning on or off individual action bits.)

+---------------
| BTW, redwood!rpw3 posted a very detailed description of one form of
| vertical microcode; as it appears in I/O devices, etc. He also mentions
| bit-sliced machines (the AMD 2900), which make for fast design of fast
| custom hardware...  | 	  

		
		
		
Report message to a moderator