roy@gitpyr.UUCP (Roy J. Mongiovi) (09/13/84)
Well,
As far as I can tell, the only way to detect the presence/absence of
the coprocessor is to read the system board switch(es) and determine if
a coprocessor is configured or not.
So as a guess, I would say that the AT switches read differently. I
know that the XT reads in an entirely different fashion than the PC, so
there seems to be a precident....
--
Roy J. Mongiovi. Office of Computing Services.
Georgia Institute of Technology, Atlanta GA 30332
Phone: (404) 894-6163, (404) 894-4660 [messages]
...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!roy
...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!roykds@intelca.UUCP (Ken Shoemaker) (09/18/84)
> As far as I can tell, the only way to detect the presence/absence of >the coprocessor is to read the system board switch(es) and determine if >a coprocessor is configured or not. Well, how about running a co-processor instruction and seeing if anything happens? If on an 8088 a coprocessor instruction is executed and there isn't anything there listening to do anything with it, *nothing* happens (suprise?) Although this will require a little assembly language (horrors) it is pretty foolproof..... -- I've got one, two, three, four, five senses working overtime, trying to take this all in! Ken Shoemaker, Intel, Santa Clara, Ca. {pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!kds ---the above views are personal. They may not represent those of Intel.
roy@gitpyr.UUCP (Roy J. Mongiovi) (09/20/84)
> Well, how about running a co-processor instruction and seeing if anything > happens? If on an 8088 a coprocessor instruction is executed and there > isn't anything there listening to do anything with it, *nothing* happens > (suprise?) Although this will require a little assembly language > (horrors) it is pretty foolproof..... > > Ken Shoemaker, Intel, Santa Clara, Ca. > {pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!kds When you issue a command to the 8087, you have no way to know when the result is complete except for issuing a WAIT instruction on the 8088. This instruction halts the machine until the 8087 interrupts it. If there is no 8087, there will be no interrupt. But here is your poor little 8088 sitting there (forever) waiting for that interrupt. How does that help detect the presence of an 8087? Is there some particular 8087 instruction that takes a predictable amount of time to execute (so that a delay loop could be built to wait for the instruction to complete) AND which produces predictable results both when the 8087 is absent and present? -- Roy J. Mongiovi. Office of Computing Services. Georgia Institute of Technology, Atlanta GA 30332 Phone: (404) 894-6163, (404) 894-4660 [messages] ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!roy ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!roy
kds@intelca.UUCP (Ken Shoemaker) (09/25/84)
If you read AP113, "Getting Started with the Numeric Data
Processor," Feb 1981 (also in the 1984 Microsystems Component
Handbook, volume 1, pp 3-1,3-61). Figure 6 shows just what you
want, as it says "This code will always recognize an 8087
independent of the TEST pin usage on the host." It does just
what you ask, showing an instruction that is "self synchronizing,"
i.e., the 8087 is guaranteed to grab the bus immediatly after the
instruction is executed so that the data value placed in memory
by the 8087 can be reliably examined without issuing the WAIT.
--
I've got one, two, three, four, five senses working overtime,
trying to take this all in!
Ken Shoemaker, Intel, Santa Clara, Ca.
{pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!kds
---the above views are personal. They may not represent those of Intel.rsellens@watdcsu.UUCP ( Mech. Eng.) (09/26/84)
You can just stick an 8087 in a PC and run it with no changes in switch settings. (I bought an 8087, rather than an IBM co-processor, and didn't get any configuration instructions.) If the chip has been put in and the switches set, then you could read them to check on the 8087, but probably better to try it and see if it works. Rick Sellens
deg@digi-g.UUCP (Dan Germann) (09/27/84)
It should be possible to determine if a coprocessor is resident by executing an instruction that changes the state of something that the 8088 can access. One instruction that would work is a store. The 8087 manual specifies the maximum execution time for each 8087 instruction, so it should be easy to compute a value for a timing loop. Since the initial contents of the 8087's registers are undefined, it probably would be a good idea to load something into the register before it is stored: FNINIT <delay> FNLD1 <delay> FNSTP <address> <delay> ; At this point, you can see whether the 8087 stored something into ; <address>. Make sure that your assembler doesn't put a WAIT opcode in front of the 8087 instructions. There are probably shorter code sequences that would give the same results.
mike@smu.UUCP (09/28/84)
#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
johnl@cca.UUCP (10/01/84)
#R:gitpyr:-20600:ima:12700001:000:1438 ima!johnl Sep 30 15:05:00 1984 Just last week, I was bitten by the 8087/80287 problem. We use Lattice C (version 2.12) and found that Lattice programs were giving totally wrong floating point results on an 80286-based IBM PC/AT. Since we had bought Lattice's library sources, I took a look to see what the problem was. Each time it does a floating point operation, the Lattice library has two sets of code, one that uses and 8087 or 287, and one that simulates it. There is a little routine that checks to see if the 87 is present. It didn't work on a 286, because the behavior of the 80286 without a 287 is different from that of an 8086 or 8086 without an 87. In the absence of an 8087, the the 8088 does nothing at all when a floating point instruction is encountered. In the absence of an 80287, an 80286 gets garbage results from the bus. It was easy to change the routine in Lattice's library to work both ways, something they say they've done in the 2.13 version that they're sending to me. Intel's 80286 programming manual has some examples; basically you do a FINIT to reset the float chip, and then see whether a FSTCW stores a zero. The issue of WAIT instructions is a red herring, since FINIT and FSTCW don't need WAITs. I've tested this on 8088's with and without 8087 and 80286 without 80287 and verified that it works. We haven't managed to get a 287 plugged into an 80286, but I'd really be surprised if it didn't work. John Levine, ima!johnl