jbm@uncle.UUCP (John B. Milton) (10/24/88)
Parts of this article are copied from mail to David Wexelblat (dwex@mtgzz.att.com), who suggested a 68881 when I asked for hw ideas. The rest of you just don't seem to have any ideas :-! I was thinking about that one a while ago. AT&T actually made a 68881 board, they even have a part number, 105160253. I talked to some guy at AT&T, and he says the board was never release due to poor performance. Since the 68010 does not have a coprocessor interface, the 68881 would have to operate as an I/O device, so it would work fine as an expansion card. David tells me that the software interface was implemented using an F-line exception handler. While this is clean from the compiler point of view (you just generate 68881 instructions), it is expensive: 1. Execute instruction 2. Get F-line exception 3. Stack everything away 4. Start running the common kernel exception code 5. Pull all the parameters from the user PC and talk to the 68881 through I/O 6. Defer to another process while the instruction runs on the 68881 7. Get an interrupt, get the status 8. Call the kernel code to return from exception. Steps 6&7 could be replaced with 6. Loop polling the 68881 for completion 7. Get the status I don't know what they did about having an expanded process context for procs using the 68881. It seems the only way to get decent speed is to have the program using the 68881 be the only one using it and to access it directly. David's idea is to modify GNU C to generate the proper I/O directly. The only code that could directly access I/O would be kernel code, like a loadable driver. It wouldn't be so fun to write all your floating point programs as loadable drivers. Hmm, you would have unlimited CPU... Nah On the other hand, there is a messy solution. The user only has access to the user memory mapped to his process. There is a routine plock(2) which might be used to lock a page so that the physical address of the page would never change and would always be there. I have never tried to use this on the UNIXpc, I just checked to make sure it's in the manual. The user address could be passed to a /dev/fpa driver via ioctl(2). The driver coulld take this address and find the physical address corresponding to it. This address could be passed from the driver to some I/O which would map the 68881 in every time there is an access to this page. When the file to this driver is closed, the mapping is disabled. The fpa device could only be opened once. The program would have to run suid to call plock(), but it could do a setuid(getuid()) once it's running, which would ba a reasonable compromise. The hardware could not be on the expansion bus for this idea, because you could not be sure that a given user page is on an expansion memory board. There could also be nasty problems if the page is used for anything else while mapped to the 68881. Some good news is that the 68881 could be run asyncronously, so it could have it's own clock. So yes, it could be a 33MHz 68882 (if they're that fast yet?). Yes, it would cost more than the machine. I don't know what the current price is for the 12.5 MHz 68881. Assuming I could whip together something that would work. How many people would be inter- ested in buying a board without the 6888[12]? Please e-mail. Ok, tell me how much of this I got wrong. Also send me any other ideas. Since this would all be done in I/O, I suppose it could be ANY over priced FPA. I know what you're thinking now, how about a DSP instead? Sure, I think all this would apply. John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu home (614) 294-4823, work (614) 764-4272; Send vi tricks, I'm making a manual
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (10/25/88)
I'd just put in a 68020 at the same time; then you get the coprocessor interface and a few other benefits. Computer System Associates in San Diego makes "daughter board" 68020/881 upgrades that plug into a 68010 socket. They come in several different shapes, so maybe one would fit in the Unix PC. There might be some minor OS problems. (And, of course, minor OS problems become major ones without source code, but I think it would be doable.) -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
thad@cup.portal.com (Thad P Floryan) (10/26/88)
Mike Ditto suggested trying one of the CSA 68020/68881 boards in the UNIXpc.
I just happen to have one here (when I replaced the 020/881 in one of my
Amigas with an 030), so I'll plug it into one of the "extra" UNIXpcs here
and see what happens!
Only see two problems:
1) the CSA daughterboard is tall, so will have to run with the UNIXpc's
hood open, and
2a) HOW can I issue the MOVEC to enable the 020's cache? (since it's a
privileged instruction)
2b) HOW to handle the stack frame differences upon interrupts?
Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]