How CPU's work (was Re: Hi, I'm new...)

Tony Duell ard at
Sun Aug 6 17:28:13 CDT 2006

> Tony Duell wrote:
> >> Hehe... abracadrabra.
> >>     
> >
> > All I can say is that it's a wonderful feeling when you finally 
> > understand how a CPU works at this level. All the magic has gone away, 
> > everything makes sense again.
> >   
> Yeah, CPU's are really very simple.  Here's my half drunken rant about
> them.  Skip this if you know how CPU's work. :-)
> Basically, CPU's fetch opcodes (instructions) and data, then decode said
> instruction, execute them, and increment their Program Counter register
> (or change it to a new value), and repeat.  The ones with microcode (or
> RISC) are easiest to understand, although you don't get to see the
> microcode.

That very much depends on the CPU. If the CPU is many chips (not a single 
package) with microcode in PROMs, there's nothing to stop you desoldering 
said PROMs and reading them out. I've done that, then written a 
disassembler for the microode instructions and worked out what was going on.

And some CPUs, the PERQ being probably the most common example, load 
their microcode from disk at power-on. In which case you might even get a 
mcirocode assembler and disassember as standard OS tools. If not, you can 
write them.

> They all are pretty much similar in that they have a register called PC
> (or IR) that point to the currently executing opcode.
> RISC ones and microcoded ones use the bits in the opcode to turn on
> circuits that do what the opcode says.  With some CPU's you can almost
> "see" the circuitry that does this by looking at the opcode tables.

This is rather a higher level tham I was considering it. I was thinking 
more along the lines of 'Decoder U55 decodes the 3-bit field consisting 
of micorocode bits 23-25. Output 4 of this decoder enables OR gate U27c 
which passes the delayed clock to the clock input of the D-type U71a. 
This stores the carry output of the ALU, and acts as a carry flag'

Yes, I do often consider CPUs at that level

> Granted, they can be complex if you're dealing with x86, but even so, if
> you were able to see what the x86 ones really do underneath the the
> layer that's masked, each piece is simple.  It's just that there are
> many, many, many pieces, which make for a complex device.

The problem is that most books describe the simple parts (gates, 
flip-flops), then the final result (CPU, at the level of 'fetch an 
instruction, decode it, increment PC'), but miss out the bit in between. 
Exactly how you can link up gates and FFs to make a CPU.


> A CPU is hooked up to a  bunch of memory.  The memory is addressable
> linearly (on most CPU's) and some of it is ROM because RAM loses it's
> data on power off.

The PERQ has no ROM in the memory map (and no, there is no frontpanel 
where you toggle in a boot loader by hand). What there is is a little 
microcode PROM that overlays the bottom part of the microcode RAM. This 
PROM contains enough microode to read the boot sector from disk into the 
mcirocode store (said boot sector of course contains microcode), that 
then reads in some more microcode, which reads in the OS into user RAM. 


More information about the cctalk mailing list