Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!apple!vsi1!altos!altos86!rcollins
From: rcollins@altos86.Altos.COM (Robert Collins)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Detecting an 80486
Message-ID: <3838@altos86.Altos.COM>
Date: 20 Aug 90 16:09:08 GMT
References: <26a858b9@ralf> <3817@altos86.Altos.COM> <1990Aug14.025550.17669@esegue.segue.boston.ma.us> <6020@darkstar.ucsc.edu>
Reply-To: rcollins@altos86.UUCP (Robert Collins)
Organization: Altos Computer Systems, San Jose, CA
Lines: 29

Whether trapping invalid opcodes, or looking for differences in the flags
register, either algorithm has its pitfalls.  The algorithm trapping invalid
opcodes can fail in V86 mode if the kernal doesn't pass control to the
to the applications invalid opcode handler.  Reportedly, QEMM and WIN386
don't do this.  As a result, both of these programs are in joepordy of
not being 100% "PC" compatible.  

On the other hand, looking for differences in the flags register has its
problems.  Though Intel supplied the code, it doesn't appear to be
DOCUMENTED anywhere in Intel literature the default state of these
flag bits.  So the problem with this technique is that it relies on
undocumented features of the chip.

In is commonly believed that C&T and some other chip manufacturers are
working on a '386 and/or '486 clone chip.  If the polarity of these flag
bits aren't documented, then there is no guarantee that clone chips, or
even Intel chips will not change their polarity.

I can certainly see advantages to both techniques.  For now, I feel
safest using a technique that relies on documented features of the
chip.  In the future, that opinion might change.  After I get a chance
to evaluate some of the clone chips, I might change to the Intel
algorithm.

-- 
"Worship the Lord your God, and serve him only."  Mat. 4:10
Robert Collins                 UUCP:  ...!sun!altos86!rcollins
HOME:  (408) 225-8002
WORK:  (408) 432-6200 x4356