jan@bagend.UUCP (Jan Isley) (10/27/89)
Now, wouldn't that be great? An 020/881 in our unix-pcs. If only ...
Yea, I know, we have talked about it before, but let us do it again.
I have a friend who designs 020/030/88000/etc... co processor boards.
The board in my Mac Plus has an 020/881 with room for 4 MB of 32 bit
memory and runs at *least* 10% faster than a Mac II at the same clock
speed. Actually, my board can run at 25 MHz, but that is not the point.
The point is, he has designed about 20 different variations of this
board. The variations go something like 020, 030, 88000, with or without
math chip, w/wo on board memory, w/wo on board memory management, with
or without a mac style SCSI port, etc...
He has done one for a VME 68000 UNIX system that has only a 68020/68881,
just take out the 68000, plug his board in, and it works. The whole thing
is only about 1/2 inch high and about the size of a playing card.
No, I have not tried this yet. But, I am getting one. Who knows, maybe
it will work. If it does not work, *and* there is a potential to sell a
bunch of boards, he is willing to spend a little time looking at it. His
usuall fee *starts* at $20,000. There is no doubt that he can get it to
work if there is a problem at first. The only real problem would be that
he does this for a living and is not a bit interested in doing charity
work for our little unix machines. Fact is he hates unix, says he does
not like sharing his computer with an operating system.
Of course, if there were enough people *really* interested in this,
interested enough to actually spend money, remember this motorola silicon
is not cheap, he might be persuaded to debug it without his usual really
big non-recurring engineering fee. I just check a couple of adds in Byte.
Single quantity prices for an 020/881 pair run $250 to $300 for 16 MHz.
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?
The other really obvious question is, would you buy one? for how much?
--
jan@bagend {..gatech..}!bagend!jan (404)434-1335 voice@homemotteler@umbc3.UMBC.EDU (Howard E. Motteler) (10/30/89)
In article <13@bagend.UUCP> jan@bagend.UUCP (Jan Isley) writes: [ discussion about adding a 6820/68881 daughter board ] >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? > >The other really obvious question is, would you buy one? for how much? > >-- >jan@bagend {..gatech..}!bagend!jan (404)434-1335 voice@home Well, the obvious software difficulty is that the 68881 reg's don't get saved in a context switch. But I would find even being restricted to a single floating point process quite usefull. The other obvious difficulty is generating code for it! I don't know about other hardware/software difficulties, but I would definitely want to buy one if it worked at all. Howard Motteler ps: Jan, do your or Discovery know anything about ethernet cards for this box? Anbody got one they want to sell? -- Howard E. Motteler | Dept. of Computer Science motteler@umbc3.umbc.edu | UMBC, Catonsville, MD 21228
botton@laidbak.i88.isc.com (Brian D. Botton) (10/30/89)
In article <13@bagend.UUCP> jan@bagend.UUCP (Jan Isley) writes: >No, I have not tried this yet. But, I am getting one. Who knows, maybe >it will work. If it does not work, *and* there is a potential to sell a Please let us know either way. >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? I have given this a little bit of thought, after all, if I was going to make a daughter board for access to video ram why, not include the 020/881 combination? From a hardware stand point, there is no reason this cannot be done. It might take a little work to get it to fit, but as Jan stated, this kind of thing has been done before. The problem is the kernel. On the surface, there are two problems: 1. I have not verified this, but the exception stack is probably different between an 010 and an 020. It is different between the 030, 010 and 000. The kernel would have to know how to deal with the slight differences. I think this would be fairly easy if you had source. 2. When there is a context switch you need to save the reigesters in the 68881, unless you want to run under the assumptiont that only one process can use the 68881 at a time, and that might not even work correctly all the time. Again, this would be easy to fix if you had source. Personally, I'de love to have the 020/881, and I was even contemplating reverse engineering part of the kernel to make it work, but it is far down on my list of things to do. Also, if it can be done, I won't charge $20k to do it, ;-). At one time I saw a Unix-PC catalog that listed a floating point accelerator. Does anyone know what this was? The C compiler does have options for a 68881. When I tried it I got a message saying I needed the 020 binary for ccom. Does this mean the FPA was on the verg of release or just that the compiler is universial in nature? Brian -- ... ___ _________ _][_n_n___i_i ________ I I Brian D. Botton (____________I_I______I_I_______I laidbak!botton or /ooOOOO OOOOoo oo oooo oo oo laidbak!bilbo!brian
jcm@mtunb.ATT.COM (was-John McMillan) (10/30/89)
In article <13@bagend.UUCP> jan@bagend.UUCP (Jan Isley) writes: [ discussion about adding a 6820/68881 daughter board ] >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? 1) I believe the 68020 interrupts generate a longer/different restart vector. (Since poltergeists have taken my manual I cannot confirm this.) The likely result of this is the BOOT ROMS, kernel and diagnostics won't work without re-writing. 2) I "have been told" that the 68020 control timings (address assertion, etc.) are radically altered, and many of us know how narrow the 3B1's tolerances are. Wouldn't it would be awkward to guarantee the reliability of any such mod'. 3) The ain't much room in the inn. Where wouldja hang the mess? 4) Those who interfaced a 68881 w/in AT&T were NOT impressed with the gains. The overhead of managing the chip reduced its floating point advantages. john mcmillan -- att!mtunb!jcm
jmm@eci386.uucp (John Macdonald) (10/31/89)
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