But the original 68000 was actually a 16 bit internal architecture -- is was made with a 16 bit barrel shifter and any 32 bit op took two ticks.  Yes, they (fortunately) did define the 32 bit data types and many of the 32 bit operations.   There was an argument at the time was it a 16 bit or 32 bit chip and between people implementing compilers - should a C "int" be 16 bits or 32.

 

Since I had hacked the Ritchie PDP-11 compiler for mine, I used 16 bits, while the MIT guys used 32 (I think they were hacking on Steve's if my memory is correct).   The advantage of the later was int == ptr and that the time V6 and V7 was definitely pointer "dirty" the worst example being the Bourne shell and how break(2) was implemented.   The advantage of the former was it was the natural size of the chip internals and so it made it easier for me to generate "optimal" (well let's just say "better") code plus that's what's Dennis's compiler "knew."

 

Jeff Mogul ended up at Stanford around that time.  He and I had a long argument about it when we first met.   We each we sure the other was wrong - :-0   Years later when we became colleagues we reminded of the old argument, I think we agreed that other was "right."   It was a tough choice and there were good arguments on both sides.

 

BTW:  I once asked Les about it during our Stellar time.  He said they thought of it as a 16 bit chip - a PDP-11 like system without running into the problem that Cal Data did with "cloning" the 11.  Les and team has been using PDP-11's before they joined Moto. But the reality is that UNIX code really wanted int==ptr for a long time [as well as:  ptr = 0; *ptr == 0].  That really was not forced to be fixed until Alpha came on the scene and people cleaned up there code.

 

 

 

 

True that the original 68000 lacked the instruction restart ability, but the MMU could be made to not need restart.

 

 

As I said this is not completely true - you just never stopped the instruction.  The fact is that a 68000 could do VM, but it took a bit of work a external logic.   Forest Basket wrote a paper on how to do it and it was actually what both Apollo and Masscomp implemented in this first products.

 

The trick was that the 68000 "CPU" could not complete the instruction when the fault occurred (or as you mentioned - the reason was that bad things happened was because the microcode did not correctly save the internal instruction state).   So the "executor" 68000 CPU was sent  wait states by the MMU -- in effect forcing it to have a very slow memory read.   While it was waiting for the memory to fill, the fault had to be handled by something else.  In Masscomp's case (and I believe Apollo also) the "fixer" was another second 68000 that ran in kernel code that handled the fault and refilled the MMU's TLB (or if you we schooled by Digital - the "TB").

 

At the time Dave Cane and Jeff ??? ( the logic designer sat Masscomp - Jeff's last name now escapes me) had been from the 11/34 and VAX projects previously.  They were horrified to have to use a second processor just for memory refills, and spent weeks trying to find a way out but eventually relented to what the SW guys where telling them.

 

As I said, when the '010 came out, Masscomp retrofitted the CPU card to allow the fault to occur and not wait state the CPU.  The RTU kernel detected the actual chip being used, and when it was running on a ' 010, would immediately do a task switch on the executor and run some other code, while the fixer handled the fault. I've forgotten now, but my memory is that the fixer always ran out of the cache.

 

BTW: the '010 originally still had VM issues that did not get fixed until the '020.  The way Moto handled the fault was to dump the state of the internal microcode to the CPU stack, and when the instruction was restarted, was to suck the state back into the processor.   The problem was that as that Moto was updating the microcode in manufacturing not thinking it was an issues for customers a processor with the step logic stepping might have different microcode - which was not a problem for 99% of their customers.

 

 

However, Masscomp actually made the first dual processor UNIX box - the MC-500/DP which was released about 12 months after the MC-500  (they predated Sequent by about 2-3 years).   A couple of months after we started shipping the DP, we started to see a strange failure in the field.  The issues was that a fault would occur on one CPU and the kernel would try to restart to the instruction on a different processor, and unless both CPU boards had executor chips from the same manufacturing lot - you had to restart in the same physical chip that took the fault.   Because the original RTU DP system was modeled on the Goble Vax, were kernel mode was on one processor at a time and the original DP had a NUMA memory system (the 5000 was SMP with UMA memory).   Thus usually, processes tended to get started on one processor and not migrate to the other, but under they could migrate.   All the test systems in engineering had matched processors - no problem.   But when field service started to swap boards, around at customer sites, bad things started to happen.

 

We had quite the panic figuring out what it was and then forced field service to ensure all CPU cards were matched -- what a pain in the tuckus.   With the 5000 when we went full SMP, we screamed at Moto and got them to clean up their act so that what was dumped on the stack could be restarted on any '020 regardless of stepping/microcode etc.

 

Clem