Newsgroups: comp.os.msdos.programmer
Path: utzoo!utgpu!watserv1!maytag!watstat!dmurdoch
From: dmurdoch@watstat.uwaterloo.ca (Duncan Murdoch)
Subject: Re: Detecting an 80486
Message-ID: <1990Aug25.000923.3762@maytag.waterloo.edu>
Sender: daemon@maytag.waterloo.edu (Admin)
Organization: University of Waterloo
References: < <3839@altos86.Altos.COM> <1990Aug21.223404.19523@ddsw1.MCS.COM> <2664@dataio.Data-IO.COM>
Date: Sat, 25 Aug 90 00:09:23 GMT
Lines: 34

In article <2664@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:
>I don't have an 80486 manual, but perhaps a more reliable way to detect
>a 486 would be to detect a difference between an 80487 and a 387. Since
>486's always have a 487 on board, this could work.
>
>Are there any differences between a 387 and a 487?

Great idea!  Yes, there's a difference:  the FINIT clears the error pointers
in the 486, but not in the 387.  That should be a really easy test!

>Are FWAITs *never* necessary with a 487?

The 486 manual says you need them if you want to be sure that operands to 
floating point instructions are unchanged when an error interrupt occurs.
The example given is
  FILD count
  INC  count
  FSQRT 
where an error occuring during the FILD won't be detected until after count has
been incremented, making recovery difficult or impossible.

A wait may be necessary after a store to memory.  For example,

  FSAVE state
  MOV   ax,state[6]

won't work, because the state won't be completely saved before the MOV reads it.
I'm not sure about other write instructions - the manual doesn't seem to
discuss the problem for them.  I'd guess that the explicit wait is necessary,
since most of them take dozens of cycles to complete.  The only exception is
the FST, which is supposed to take only 6-8 cycles.

Duncan Murdoch
dmurdoch@watstat.waterloo.edu