Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site smu.UUCP
Path: utzoo!watmath!clyde!burl!hou3c!hocda!houxm!ihnp4!inuxc!pur-ee!uiucdcs!smu!mike
From: mike@smu.UUCP
Newsgroups: net.micro.pc
Subject: Re: Detection of the Math Co-processor - (nf)
Message-ID: <15000006@smu.UUCP>
Date: Thu, 27-Sep-84 17:10:00 EDT
Article-I.D.: smu.15000006
Posted: Thu Sep 27 17:10:00 1984
Date-Received: Sun, 30-Sep-84 00:57:34 EDT
References: <206@gitpyr.UUCP>
Lines: 30
Nf-ID: #R:gitpyr:-20600:smu:15000006:000:1201
Nf-From: smu!mike    Sep 27 16:10:00 1984

#R:gitpyr:-20600:smu:15000006:000:1201
smu!mike    Sep 27 16:10:00 1984

<>

A WAIT instruction does not cause the processor to wait for an
interrupt, but rather to wait for another pin (the TEST pin) to be
to go either high or low (I can't remember).  A system could easily
strap this pin appropriately so that a WAIT instruction would not hang
the CPU.

Ken Shoemaker is correct in his statement about detecting a
coprocessor by seeing if an ESC instruction works, provided the above
is true of the hardware.  To take advantage of this capability in
order to provide run-time decision as to whether or not to emulate
floating point instructions, one would have to explicitly code in
calls to some emulator along with the regular floating point
instructions.  How one would achieve this from a high-level language
without basically writing two versions of the software is not clear to
me.

The 286 (and the 186 for that matter) is nicer than the 86 in this
respect.  It has a couple of status bits which will cause an interrupt
to occur upon detection of a floating point opcode if the bits are
set.  The emulation code could thus be something included in the
operating system at OS config time, and software would not know the
difference.

Mike McNally
...convex!smu!mike