Message-ID: <37A96C09.95FC9A2@softhome.net>
Date: Thu, 05 Aug 1999 12:48:41 +0200
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: CPU ID program, second version
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990804162240 DOT 1514C-100000 AT is> <37A8643F DOT CCFFBD9A AT softhome DOT net> <199908050211 DOT EAA28717 AT tyr DOT diku DOT dk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Morten Welinder wrote:
> Just, FYI, this algorithm (setting AC flag, then ...) will not work in
> all environments.  In particular, you have no guarantee that the AC
> flag will be turned on if the underlying DPMI does not feel like it.
> The manual page ought to say this.  I don't think a bulletproof
> algorithm exists outside ring 0/real mode.

No. This algorithm does not depend on particular state of flag - it
is based on fact that 386 is unable change AC flag at hardware level.
It does not set nor clear the flag, it tries to toggle it instead.
And software environment cannot do anything about CPU's inability to
change the state of flag.

> Also, your switch statement is incomplete -- add a default case and
> call it "ix86" or something like that.

It currently handles all cases - first CPU's with CPUID instruction
are 486 and Pentiums. And currently there is no CPU which reports
bigger value in "instruction family" field than 0x6 (for i686).

Laurynas Biveinis