[net.micro.pc] Identifying an iAPX series processo

kevin@trsvax (03/20/86)

> Question: is it possible to identify in software the type of processor
> a program is running on (assuming MS-DOS here...)?  I would like to
> know whether it's an 8088, 8086, 80188, 80186 or an 80286.  If it
> is possible, how do I do it?

Yes, it is possible, at least to distinguish between {8086|8088},
{80186|80188}, and 80286 flavors of processors.  The 8086 (and the 8088,
I guess) don't mask shift counts, so if you shift a 2 in AX by a number
of places greater than 16 (?or 32, maybe -- 32 works for sure) you'll
get a zero.  On the 186 and 286 you'll get a non-zero value.  To
distinguish between the 186 and the 286, do a PUSH SP, pop it into
another register and compare it.  The 186 pushes the SP value *after*
it's been decremented, the 286 pushes the SP value *before* it's
decremented.

I don't know if you can tell if you're on a *8 or *6 version processor,
though.

Good luck!
Kevin Dack
..ctvax!trsvax!kevin

john@moncol.UUCP (John Ruschmeyer) (03/23/86)

In article <53500027@trsvax> kevin@trsvax writes:
>
>> Question: is it possible to identify in software the type of processor
>> a program is running on (assuming MS-DOS here...)?  I would like to
>> know whether it's an 8088, 8086, 80188, 80186 or an 80286.  If it
>> is possible, how do I do it?
>
>Yes, it is possible, at least to distinguish between {8086|8088},
>{80186|80188}, and 80286 flavors of processors.  The 8086 (and the 8088,
>I guess) don't mask shift counts, so if you shift a 2 in AX by a number
>of places greater than 16 (?or 32, maybe -- 32 works for sure) you'll
>get a zero.  On the 186 and 286 you'll get a non-zero value.  To
>distinguish between the 186 and the 286, do a PUSH SP, pop it into
>another register and compare it.  The 186 pushes the SP value *after*
>it's been decremented, the 286 pushes the SP value *before* it's
>decremented.
>
>I don't know if you can tell if you're on a *8 or *6 version processor,
>though.

Yes, but it requires writing self-modifying code. The trick is that the *6
and *8 processors have different pre-fetch queue sizes.

For a difinitive answer on the subject- RUN, DO NOT WALK to the nearest
newstand and pick up the April PC Tech Journal. There is a big article
(including asm source) about doing exactly what you want.


-- 
Name:		John Ruschmeyer
US Mail:	Monmouth College, W. Long Branch, NJ 07764
Phone:		(201) 571-3451
UUCP:		...!vax135!petsd!moncol!john	...!princeton!moncol!john
						   ...!pesnta!moncol!john

"I killed him... and he thanked me. Why did he have to be so nice about it?"

cgf@infinet.UUCP (Chris Faylor) (03/23/86)

{}
>
> Question: is it possible to identify in software the type of processor
> a program is running on (assuming MS-DOS here...)?  I would like to
> know whether it's an 8088, 8086, 80188, 80186 or an 80286.  If it
> is possible, how do I do it?

The April 1986 (Vol. 4, No. 4) issue of PC TECH Journal has an article
titled "Chips in Transition" which has routines to distinguish between
the different flavors of CPUs.
-- 
			-cgf-

I feel more like I do now than I did when I first got here.

		decvax!wanginst!infinet!cgf
		emacs!infinet!cgf@cca-unix.ARPA

ijk@mtung.UUCP (Ihor Kinal) (03/26/86)

> 
> > Question: is it possible to identify in software the type of processor
> > a program is running on (assuming MS-DOS here...)?  I would like to
> > know whether it's an 8088, 8086, 80188, 80186 or an 80286.  If it
> > is possible, how do I do it?
> 
> Yes, it is possible, at least to distinguish between {8086|8088},
> {80186|80188}, and 80286 flavors of processors.  The 8086 (and the 8088,
> I guess) don't mask shift counts, so if you shift a 2 in AX by a number
> of places greater than 16 (?or 32, maybe -- 32 works for sure) you'll
> get a zero.  On the 186 and 286 you'll get a non-zero value.  To
> distinguish between the 186 and the 286, do a PUSH SP, pop it into
> another register and compare it.  The 186 pushes the SP value *after*
> it's been decremented, the 286 pushes the SP value *before* it's
> decremented.
> 
> I don't know if you can tell if you're on a *8 or *6 version processor,
> though.
> 
> Good luck!
> Kevin Dack
> ..ctvax!trsvax!kevin

The latest issue of the PC TECH Journal (April 86) discusses these issues
(including differentiating from the NEC 20/30, and includes a test
program.  Their way off differentiating an 8/6 is to make use of the
fact that they have different length instruction buffers.
Ihor Kinal
ihnp4!mtung!ijk
P.S.  One discrepancy: the article claims that in a 286, it's
no longer legal to say MOV CS, AX; nor can one say POP CS.
Using DEBUG, I tried both; the MOV CS,AX seemed ok, the POP CS
totally hung the machine. If both were true, then how could a program
reset the CS register????

mnl@cernvax.UUCP (03/30/86)

     One way in which you could tell the difference between an 8088
and an 8086 (and probably between an 80188 and an 80186, but I've never
seen any documentation for either chip) is to take advantage of the
instruction prefetch queue.  The 8088 has a five byte prefetch que,
the 8086 an 8 byte prefetch queue.  So if you wrote a self modifying
program that did something like replace a set carry flag instruction
six bytes ahead with a clear carry flag instruction, you could then
do a branch on carry to appropriate routines for each processor.


Mark Nelson
-- 
mnl@cernvax.bitnet or ...!seismo!mcvax!cernvax!mnl
"This function is occasionally useful as the arguement to a function
which requires a function as an arguement."  Guy Steele, Jr.

vch@rruxd.UUCP (Kerro Panille) (03/31/86)

>     One way in which you could tell the difference between an 8088
>and an 8086 (and probably between an 80188 and an 80186, but I've never
>seen any documentation for either chip) is to take advantage of the
>instruction prefetch queue.  The 8088 has a five byte prefetch que,
					     ^^^^^^^^^
>the 8086 an 8 byte prefetch queue.  So if you wrote a self modifying
	     ^^^^^^
>program that did something like replace a set carry flag instruction
>six bytes ahead with a clear carry flag instruction, you could then
>do a branch on carry to appropriate routines for each processor.
>
>Mark Nelson

I belive those are 4 bytes and 6 bytes, if I'm not mistaken. I don't have my
PC Tech Journal handy.
-- 
Vince Hatem                           +----------------------------------------+
Bell Communications Research          ! "..., isn't that right, Daniel?"       !
Raritan River Software Systems Center ! "When you get that look on your face,  !
444 Hoes Lane                         !  Marty, I go prune my roses."          !
4D-340                                !                   -Frank Herbert       !
Piscatway, NJ 08854                   !                   Chapterhouse: Dune   !
(201) 699-4869             	      !                   pg 459               !
{rrux?, pyux?, bellcore, topaz,       +----------------------------------------+
       ihnp4}!rruxo!vch                    

bright@dataioDataio.UUCP (Walter Bright) (03/31/86)

In article <685@mtung.UUCP> ijk@mtung.UUCP (Ihor Kinal) writes:
>P.S.  One discrepancy: the article claims that in a 286, it's
>no longer legal to say MOV CS, AX; nor can one say POP CS.
>Using DEBUG, I tried both; the MOV CS,AX seemed ok, the POP CS
>totally hung the machine. If both were true, then how could a program
>reset the CS register????

Easy:
	Use the JMP FAR instruction.
	Use the CALL FAR instruction.
	Use the RET FAR instruction. (Note that there is no mnemonic for
		this instruction in MASM 4.0. You have to muck with the
		PROC pseudo op or write a macro to do it. Ug.)
	Use the IRET instruction.
	Use the INT instruction.

If you use a MOV CS,AX, you deserve what you get. You have to be very
clever to get the IP right to execute the next instruction. A lot cleverer
than to set up a JMP FAR instruction.