Xref: utzoo unix-pc.general:3991 comp.sys.att:7918
Path: utzoo!attcan!telly!eci386!jmm
From: jmm@eci386.uucp (John Macdonald)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: 68020/68881 Anyone?
Keywords: faster faster faster
Message-ID: <1989Oct30.174649.18611@eci386.uucp>
Date: 30 Oct 89 17:46:49 GMT
References: <13@bagend.UUCP>
Reply-To: jmm@eci386.UUCP (John Macdonald)
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
Lines: 48

In article <13@bagend.UUCP> jan@bagend.UUCP (Jan Isley) writes:
>Now, wouldn't that be great?  An 020/881 in our unix-pcs.  If only ...

  [...]

>I am neither a software or hardware gooroo, can't even spell it, but some
>preliminary questions come to mind for the gurus out there:

>  Are there any *known* reasons why an 020/881 would present a problem 
>  hardware wise?  I think this would be the easy part?

>  Any 020/881 fatal code in the software?

There are a couple of major problems.  The 68020 uses a different format
for exception stack frames, so there would need to be significant changes
in the kernel to handle this.  The floating-point registers would have to
be saved as part of the process state.  There are some difficult interactions
for handling intra-instruction traps - if a signal comes along at the wrong
time, you can't just fudge the stack frame, but have to use a trace trap to
continue to a proper instruction boundary before allowing the signal to be
processed.  Existing programs/compilers might not be able to take advantage
of the 68881 (I have never looked to see whether the current setup implements
floating point as a subroutine library invoked by the compiler, or whether it
generates floating point instructions and simulates them in the kernel; if the
former, then adding a 68881 will only help if you rewrite the library and
relink the programs, if the latter, then the existing code should run without
change (except the saving FP regs as mentioned above).

Using a 68030 instead would have the same set of problems.  In addition, to
*use* the internal mmu of the 68030 would add a lot of changes to the kernel;
it would probably be necessary to just run the 68030 with the mmu disabled
and use the existing memory management hardware (whatever it is) of the Unix-PC.

>The other really obvious question is, would you buy one?  for how much?

>-- 
>jan@bagend  {..gatech..}!bagend!jan  (404)434-1335 voice@home

I would love to have the 3b1 run faster, but it sounds like a lot of work
to get running well.  (I have done a port of System III from a 68000 to a
68020 before, although there were more differences that had to be accomodated
in the other conversion than would be required for the 3b1.  In that
conversion, it was a different processor board that was being used, a different
mmu mechanism, and a different byte-order for accessing things on the bus.)
-- 
"Software and cathedrals are much the same -          | John Macdonald
first we build them, then we pray" (Sam Redwine)      |   jmm@eci386