lenny@icus.islp.ny.us (Lenny Tropiano) (10/23/88)
In article <3462@rphroy.UUCP> tkacik@rphroy.UUCP (Tom Tkacik) writes: |>In article <368@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: |>>First thing's first. If you have ANY ideas for hardware enhancements, e-mail |>>them off to me. Let me know about any special deals for hardware that give |>>you the idea and all possible uses you can think of. You will get credit |>>for your idea in the form of recognition, but that's all! |> |>Fair enough. I would like to put a floating point chip in my machine. It is |>just too slow without it. It's embarassing to get beaten by XT's and |>turbo-amigas, etc. |> |>I think the hardware should be fairly easy. Either an internal daughter board |>or an expansion board, along with all of the disk drive circuits. |>The software will be the tricky part. First the math libraries will need to |>be re-written, and made compatible with the existing ones. I'm not to sure about this, but reading the UNIX System V User's Manual (vol. II) on cc(1), I saw this: "The C compiler uses one of three code generators for the CPU=xxxxx,FPU=yyyyy where CPU indicates the central processor to generate for and FPU indicates the style of floating-point math to use. xxxxx must currently be 68010, and yyyyy may be 68881 or SOFTWARE. The FPU parameter may be deleted, the default is SOFTWARE. The CENVIRON variable should always be set to the appropriate values in the .profile or .kshrc files." I'm not sure if this is actually true, but if someone was able to interface the MC68881 math acc. unit to the UNIX PC, the software problems might not be too hard. Of course without system source, you wouldn't be able to recompile anything in the system to utilitize the FPU. Also for some other tidbits, in the AT&T UNIX PC Service and Parts Ordering Information there is this: Comcode 105160253 Math. Acc. Unit MC68881 Now for the disappointing news... I spoke with someone at AT&T who told me that they either never came out with this board, or it was discontinued because of the price being way too high. I would imagine the board was "reality" if there was a comcode. It isn't available anymore if it ever was. Hope this helps in the quest for enhancing hardware on the UNIX PC! -Lenny -- Lenny Tropiano ICUS Software Systems [w] +1 (516) 582-5525 lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576 {talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny attmail!icus!lenny ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752
jrmacmillan@lily.waterloo.edu (John R. MacMillan) (10/24/88)
In article <528@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: |I'm not to sure about this, but reading the UNIX System V User's Manual |(vol. II) on cc(1), I saw this: | | [ stuff about CENVIRON deleted ] | |I'm not sure if this is actually true, but if someone was able to |interface the MC68881 math acc. unit to the UNIX PC, the software problems |might not be too hard. Of course without system source, you wouldn't |be able to recompile anything in the system to utilitize the FPU. No dice. All it does is call a different compiler instead of /lib/ccom: /lib/ccom20 if you say the CPU is a 68020, /lib/ccom20.81 if you want the 68881. And you can't use the 68881 unless you also specify you want the '020. I don't know about anyone else, but I don't even have these other compilers (not that I'm surprised). -- John R. MacMillan Space. The final frontier. jrmacmillan@lily.waterloo.edu Also a cool place to hang out ...!watmath!lily!jrmacmillan for the evening.
vern@zebra.UUCP (Vernon C. Hoxie) (10/24/88)
In article <528@icus.islp.ny.us>, lenny@icus.islp.ny.us (Lenny Tropiano) writes: > In article <3462@rphroy.UUCP> tkacik@rphroy.UUCP (Tom Tkacik) writes: > |>In article <368@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: > |> > |>The software will be the tricky part. First the math libraries will need to > |>be re-written, and made compatible with the existing ones. > > I'm not to sure about this, but reading the UNIX System V User's Manual > (vol. II) on cc(1), I saw this: > > "The C compiler uses one of three code generators for the > > CPU=xxxxx,FPU=yyyyy The Motorola Manual for the 68010 gives the following: "Word patterns with bits 12-15 equaling 1010 or 1111 are distinguished as unimplemented instructions and separate exception vectors are given to these patterns to permit efficient emulation. This facility allows the operating system to detect program errors, or to emulate unimplemented instructions, such as the MC68881 Floating Point Coprocessor instructions, in software." The idea was that if a co-processor is on board, the control is handed over to it, otherwise the Supervisor mode will process the data in software. Now the question is: Did ATT/Convergent implement the software with this in mind? or did they put all the options control in the compiler? If they built the software as Motorola designed the chip, the FPU instructions were used and trapped to software emulation. The object code produced would then work whether the machine had an FPU or not. It would just run slower if not. This is going to take some reverse engineering with a dis-assembler if someone at ATT doesn't come up with a definitive answer. -- Vernon C. Hoxie {ncar,nbires,boulder,isis}!scicom!zebra!vern 3975 W. 29th Ave. voice: 303-477-1780 Denver, Colo., 80212 uucp: 303-455-2670
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (10/24/88)
In article <528@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: > "The C compiler uses one of three code generators for the > > CPU=xxxxx,FPU=yyyyy > > where CPU indicates the central processor to generate for and > FPU indicates the style of floating-point math to use. Since the 881 version of the code generator is a separate executable (/lib/ccom20.81 used in place of /lib/ccom) and it is not provided with the Unix PC, it is not possible to generate 68881 code with the standard compiler. The stock assembler WILL assemble 68020 and 68881 code, and adb disassembles it fine as well. I have a version of GCC modified to use the CENVIRON variable in this way, and it generates normal Unix PC code or 68020/68881 code (or 68010/68881, which is what would be needed here). There is already some kind of support for the "fpa board" in the math library; various math routines call "FPA_check" or something like that to see if it's there. I've never bothered to see what they do differently when it's there, though. In particular, I don't know whether 68881 opcodes are used to cuase an illegal instruction trap in the kernel to access the '881 or if it is accessed directly (via I/O). Actually, I don't think the compiler was meant to use 68881 instructions without a 68020. Running "CENVIRON=CPU=68010,FPU=68881 cc t.c" results in: "cc: incompatiable combination of fpu/cpu in CENVIRON". -- -=] 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