Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!rutgers!mcdchg!ddsw1!nvk
From: nvk@ddsw1.MCS.COM (Norman Kohn)
Newsgroups: comp.unix.sysv286
Subject: Re: hardware incompatibilities
Message-ID: <1990Nov16.011848.28800@ddsw1.MCS.COM>
Date: 16 Nov 90 01:18:48 GMT
References: <1990Nov5.142101.1@acad3.fai.alaska.edu> <1990Nov13.091201.1@acad3.fai.alaska.edu>
Reply-To: nvk@ddsw1.MCS.COM (Norman Kohn)
Organization: ddsw1.MCS.COM Contributor, Wheeling, IL
Lines: 28

In article <1990Nov13.091201.1@acad3.fai.alaska.edu> fsdal1@acad3.fai.alaska.edu writes:
>In article <1990Nov5.142101.1@acad3.fai.alaska.edu>, fsdal1@acad3.fai.alaska.edu writes:
>> Has anyone had any difficulties running the following hardware with uPort
>> sys V/AT ?
>> 
>> 80287 coprocessor
>
>I removed my 80287 chip and now I am able to compile Pcomm, it seems that
>the 287 was interfering with the compile of x_rcv.c and x_send.c modules.


It's been a long time since I ran uport V/AT, but I did at one
time run it on a board with 80386 and 80287 (that's right).
                                        ^
It ran fine... in fact, at one point it was necessary:  I don't remember
how it came to pass, but at one point unix got strange ideas about
whether a math coprocessor was installed.  The effect was errors
in code (like awk) that used real arithmetic.  There's a kernel
variable that identifies the presence of a coprocessor, and
it was getting set incorrectly at boot-up.  It's referred to
somewhere in the docs, but I don't recall its name.  You might
as an experiment try code doing real arithmetic... though I don't see
how that should be an issue in your compilation.

-- 
Norman Kohn   		| ...ddsw1!nvk
Chicago, Il.		| days/ans svc: (312) 650-6840
			| eves: (312) 373-0564