🚀 go-pugleaf

In article <703@umbio.MIAMI.EDU> jherr@umbio.MIAMI.EDU (Jack Herrington) writes:
> Now I have to admit I will agree with that, and the 88000 series is very
> impressive, both lines beat Intel architecture hands down, but...
>
>>				Motorola High-End Marketing
>                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                               Look, ma, no bias here!
> -Jack
> University of Miami

In my own defense, I didn't work for Motorola in 1979, I worked for Signetics.
At that time, Sig was preparing to enter the 16-bit MPU wars with a proprietary
microprocessor based on the Philips P-800 minicomputer architecture (the
MPU was to be called the SP16/10). When Motorola came out with the 68K my
department was given the task of comparing the two architectures and deciding
which we thought would be "better" for Sig to manufacture.  We didn't have any
say in the final decision however. I wrote the Sig training course on the
68000, and in the process became quite enamoured with the part.  I didn't
come to work for Motorola until about 2 years later, and then as a field
Systems Engineer in the San Jose Sales office.  I moved to Austin with the
High-End group in December of 1983, after the introduction of the 68020. My
job has NOTHING to do with reading email and defending Motorola or the 68000
family, but I still like the part, and am still amazed when I realize the
history surrounding its development.  Am I biased...YOU BET, but it's
because I firmly believe that the 68K family is the best thing that ever
happened to microprocessing (to coin a term).

In article <5537@hoptoad.uucp> Tim Maroney writes:
> C'mon, Tom, let's admit that the 68000 non-recoverable bus error is a serious
> screw-up.  Just 'cause you work for Motorola doesn't mean you have to say
> everything they did is perfect; a non-recoverable exception is a bad idea.
> ...  Why'd you fix it if it wasn't broken?
> Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim

In 1979 when the 68000 was introduced, the whole concept of exception
processing was new to the microprocessor community. The 68000 was one of the
first (if not THE first) microprocessor to completely trap ALL unused op
codes (those things that made using HP calculators so much fun :>)). The fact
that the 68000 even tries to save some information about non-recoverable
external faults was innovative in microprocessors at the time.  

Remember that the term "workstation" had yet to be coined, virtual memory 
had NEVER been attempted in microprocessor-based systems, and most MPUs were 
still being used as logic replacements or embedded controllers rather than 
computing elements per se.  The 68000 changed all of that. 

On a bus error, the 68000 didn't just die, but allowed the user to
attempt to continue...maybe by trashing the offending task and returning to
the system, but continue nonetheless. Prior MPU-based systems usually performed
a cold-start or went off to try to execute bad data when an external error
was encountered.  

The 68000 saves a substantial amount of information on a bus
error:  the PC, status register, instruction register, access address, and
some basic information about the state of the processor; whether or not the
error occured on a read or write cycle, whether or not the processor was in
the middle of instruction processing, and the function codes; all at the 
moment of the error.  The major difficulty in attempting FULL recovery stems
from the fact the the PC value is advanced between 2 and 10 bytes from the
start of the instruction in which the error occured.  This is because the
PC value saved is actually the ScanPC (an internal PC used to increment
through the extension words of instructions).  

Theoretically, it is possible to implement FULL recovery given this 
information using instruction RESTART rather than INSTRUCTION CONTINUATION 
(like the '010). Instruction RESTART is the fault handling method used on 
the Intel 80[1-3]86.  One needs to look backward in the instruction stream 
for 2 to 10 bytes for the value contained in the saved instruction register.
This points you directly at the start of the offending instruction.  Once 
external memory has been "fixed" (no simple task), the instruction can be 
restarted by pushing the saved status register and the address of the 
offending instruction on the stack and issuing an RTE instruction.  
The kicker here is that it is possible for the extension words of the 
offending instruction (i.e. those between the actual instruction
address and the saved PC value) to be the same hex value as that of the
instruction itself.  Thus, you **might** start executing in the middle of an
instruction.  Additionally, the post-increment and pre-decrement addressing
modes on the 68000 mean that it is possible that address registers have been 
modified.  The bus error handler would have to determine whether or not one 
of these modes was being used and correct the appropriate address register
prior to restarting the instruction.  It is for these reasons that the 68000 
is not recommended as a processor in a virtual memory system.  

The 68010 added the features to allow for full support of virtual memory/
virtual machine environments.  Note I said **ADDED** not **FIXED**.  The 
major changes required were 1) saving more state information on bus errors, 
2) adding microcode to allow instruction continuation, and 3) making the 
"MOVE SR,<ea>" instruction priveleged.  These changes required additional 
control points in the hardware, additional microrom space, and additional 
nanorom space, none of which were available in the 68000 due to die size 
limitations.

Refering to my Model-T metaphore from yesterday: you can race a model-T, but
you'll probably get better results with a Lotus, yet BOTH use a 4-cylinder
engine!  The Model-T was the epitome of technology for its time, and can
STILL provide reliable transportation depending on your needs.
 ___________________________________________________________________________
| Disclaimer:  The views presented above are my own, and do not necessarily |
|	       reflect the views or policies of Motorola.		    |
|									    |
| tomj@oakhill.UUCP		Tom Johnson				    |
|				Motorola High End Marketing		    |
|				Austin, TX				    |
|___________________________________________________________________________|