7 Aug
2006
7 Aug
'06
10:18 a.m.
CRC wrote:
On paper, a *delightful* processor (chip set). Unfortunately,
NS went on to develop the rest of the family (332, 532, etc.)
without real concern for fixing some of the blemishes in the
original parts (N.B. the original part was the 16032 -- later
renamed 32016 :> I think I still have a databook with *that*
on it's title page)
Ray Arachelian <ray at arachelian.com> wrote:
The excitement was for a good part due to the excellent marketing on the
part of Motorola.
And, motogorilla lined up LOTS of second-sources for the part
(IIRC, *8*?) -- though they didn't all source the other devices
(e.g. '010). Back then, having a second source was good
insurance -- nowadays, I don't think ANYTHING is second
sourced at a drop-in replacement level... :-(
Tony Duell
wrote:
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. 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. 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 useless.
And, the MMU was an amusing "sit-alongside" implementation...
add it and a clock cycle to accesses and you get a two-level
paged MMU. With a small PLA, you could even design the
glue logic to allow the device to be "transparently" added
to the circuit without having to cut foils, etc.
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.
The FPU was a bit minimalist. Very different approach from
Intel's x87 or AMD's 9511? (I forget the P/N). It wasn't
do "kitchen sink" but, rather, just concentrated on basic
support for floats (w/o things like transcendentals).
Since it was so minimalist, you didn't NEED to have the
FPU running "in parallel" with the CPU (a la x87 -- which
could be grinding away for a LONG time on transcendental
evaluation). It made writing real-time kernels easier
since you didn't have to reschedule support for FPU
context saves independant of the CPU's state.
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.
NS was ALWAYS stupid in their marketing of processors!
Their GNX tools were pretty respectable, though (one of the
reasons I wanted to get my Opus PM back up and running was
to have access to that tool suite). OTOH, their ICE was
almost laughable -- almost the size of an EXORMACS/desktop PC!