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

CRC technobug at
Mon Aug 7 04:12:52 CDT 2006

On Sun, 06 Aug 2006 22:41:36 -0400 and Sun, 06 Aug 2006 22:47:23  
-0400, Ray Arachelian <ray at> wrote:

> Absolutely.  The 68000 is an amazing little chip when you compare  
> it to
> the 6800 and 6502's that it evolved itself from.  You can sort of  
> get a
> feel from this from this journal:
> It's worth a read to get a feel of the excitement the 68K caused  
> back in
> the day when it was introduced.  Some of it is very funny, there's one
> issue where the author compares an Intel FPU to the 68000 running
> software floating point routines, and guess what, the 68000  
> actually ran
> FASTER!  :-)

The excitement was for a good part due to the excellent marketing on  
the part of Motorola.

> Tony Duell wrote:
>> 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.
> True, but you don't find CPU's made of discrete logic these days,  
> so it
> makes it very difficult to get at the microcode.

In the early '80s we started development of a process controller and  
evaluated the 68K as well as the National 32K processor which had  
been just released. The NS 32K processor was released with a FP unit  
which we required while Moto didn't get around to getting one to  
market for another year - the 68K on software just didn't hack it. We  
went with the NS 32K and were quite pleased with the beast.

It was a true 32 bit processor witch came in three flavors: 8 bit, 16  
bit, and 32 bit external busses - you could move the code from one to  
the other with almost no change. The instruction set was extremely  
orthogonal and close to those of the VAX sans the three operand  
instructions. The only flaw we noted was that the entire machine  
state was not saved on interrupt/trap which made a couple of features  

The floating point processor was not a co-processor ala the 68K, but  
a external instruction execution module. When the FPU was attached,  
the FP instructions became active and you worked between internal  
register pairs. IIRC they also made communication processor that  
implemented part of the unimplemented instruction set. I played with  
my own external processor to implement macro instructions that were  
used to optimize execution time.

When Apple was evaluating processors for the Mac, an internal source  
told me that NS marketing only made a half*** effort to sell the  
part. Unfortunately NS did their normal thing when it came to  
processors and shot themselves in the foot (see PACE - both  
Studebaker and NS screwed those up) by trying to keep it all to  
themselves. Consequently, there was little third party support for  
the chip. I believe it to be a better implementation than the 68K.


More information about the cctalk mailing list