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