vereijken@rulcri.leidenuniv.nl (Jan Joris Vereijken) (03/27/91)
Hi, It turns out that Turbo Pascal 6.0 generates 80286-specific code (with the $G+ switch) that runs on a V30 chip. Comes the next logical question: How do I find out which processor I'm being run on? See, I want my program to print a nice "This program does not work on 8088/86 based machines." whenever someone tries that. There *is* a demoprog in the Turbo 6.0 distribution, but that one only detects only "80286" or "no 80286". On a V30 is says "no 80286", which is correct, but not of much use in my case. Actually, I want more, I want a way where I can decide wheter I'm dealing with: 8088 / 8086 / 80188 / 80186 / V20 / V30 / 80286 / 80386 / 80486 Ambitious, eh? Well, it should be possible: for example Norton System Info gived the processor type. Hmmm... Oh well, making a distinction between 8088,8086 / V20,30 / 80286,386,486 would be nice for starters. Kind regards, - Jan Joris Vereijken -
cd5340@mars.njit.edu (David Charlap) (03/28/91)
In article <1991Mar26.223512.1@rulcri.leidenuniv.nl> vereijken@rulcri.leidenuniv.nl (Jan Joris Vereijken) writes: > >8088 / 8086 / 80188 / 80186 / V20 / V30 / 80286 / 80386 / 80486 > >Ambitious, eh? Well, it should be possible: for example Norton System Info >gived the processor type. Well... You can try executing a 386-specific instruction, and see if it executed properly. An innocuous instruction like BT (bit test) shouldn't clobber another processor type. Do the same for the 186 test. Try the INS (read a string from a port) from a port whose contents you already know (try getting the video mode status and compare it to the current mode, maybe). Or to be even safer, use an extended 8088 instruction, like the new form of ROL and ROR (rotate bits) with an offset other than 1. To tell a 286 from a 186, you'll have to kick it into protected mode, see if it worked or not, and then do a chip reset to get it out of protected mode. To tell a V20/V30 from an 8088/8086, ya got me. Maybe Peter Norton mentions it in his book, since his program can tell them apart. I can't find any way in the Turbo Assembler book. The book doesn't mention the '486, either, so I don't know what you'd do about that one either. In any case, you have to do something that is (more or less) unique to the chip you're testing for. -- David Charlap "Invention is the mother of necessity" cd5340@mars.njit.edu "Necessity is a mother" Operators are standing by "mother!" - Daffy Duck
dave@tygra.UUCP (David Conrad) (03/28/91)
In article <1991Mar26.223512.1@rulcri.leidenuniv.nl> vereijken@rulcri.leidenuniv.nl (Jan Joris Vereijken) writes: >Hi, > > >Actually, I want more, I want a way where I can decide wheter I'm dealing with: > >8088 / 8086 / 80188 / 80186 / V20 / V30 / 80286 / 80386 / 80486 The only one I know how to do is 86,186,286 vs. 386,486 (the i586 is due out this year!). The 386 only looks at the low 5 bits of CL when shifting (hey, the registers are only 32 bits wide, why would you need to shift farther than that!) The earlier processors are not so smart. They do what you tell them, even if it makes no sense (the way computers *should* work! :). mov ax, 1 mov cl, 33 ; or 21, if .RADIX 16 (hex) shl ax, cl ; don't use extended shl instruction, may be on 8086/88 jnz atleast386 atmost286: ... atleast386: ... On 286's and previous all the bits would be shifted right out of AX, but on the 386, 486, and (presumably) 586 shl ax, 33 is equivalent to shl ax, 1, so AX ends up with 2 in it. I don't know if the equivalent TPas would work: If (1 SHL 33) = 2 then (* 386+ *) else (* 286- *); If some kind soul with a 386 would run the following test program, I'd be grateful: begin writeln (1 SHL 33); end. Damn! It produces 2 on my 286!?! Either TP is too smart, or my information is wrong. I got the info from a magazine, Dr. Dobbs I think. Confusedly, Dave Conrad dave%tygra@sharkey.cc.umich.edu -- = CAT-TALK Conferencing Network, Computer Conferencing and File Archive = - 1-313-343-0800, 300/1200/2400/9600 baud, 8/N/1. New users use 'new' - = as a login id. AVAILABLE VIA PC-PURSUIT!!! (City code "MIDET") = E-MAIL Address: dave%tygra@sharkey.cc.umich.edu
dave@tygra.UUCP (David Conrad) (04/01/91)
In article <1991Mar28.094957.11834@tygra.UUCP> dave@tygra.UUCP (David Conrad) writes: >In article <1991Mar26.223512.1@rulcri.leidenuniv.nl> vereijken@rulcri.leidenuniv.nl (Jan Joris Vereijken) writes: >>Hi, >> >> >>Actually, I want more, I want a way where I can decide wheter I'm dealing with: >> >>8088 / 8086 / 80188 / 80186 / V20 / V30 / 80286 / 80386 / 80486 > >The only one I know how to do is 86,186,286 vs. 386,486 (the i586 is due out >this year!). The 386 only looks at the low 5 bits of CL when shifting (hey, >the registers are only 32 bits wide, why would you need to shift farther >than that!) The earlier processors are not so smart. They do what you tell >them, even if it makes no sense (the way computers *should* work! :). > >On 286's and previous all the bits would be shifted right out of AX, but on >the 386, 486, and (presumably) 586 shl ax, 33 is equivalent to shl ax, 1, so >AX ends up with 2 in it. I don't know if the equivalent TPas would work: > > If (1 SHL 33) = 2 then > (* 386+ *) > else > (* 286- *); > >Damn! It produces 2 on my 286!?! Either TP is too smart, or my information >is wrong. I got the info from a magazine, Dr. Dobbs I think. > Well, the problem was my memory was bad (in head, not computer). As the Turbo Assembler Quick Reference Guide tells me, the 80286/386 only allows shifts of up to 31 bits for max. speed, but the 8086 allows 8 bits of shift in CL. So this is the right test, but it differentiates between 8086/8088 and later. (Not sure about 186.) Sorry to have posted incorrect information. Dave Conrad dave%tygra@sharkey.cc.umich.edu -- = CAT-TALK Conferencing Network, Computer Conferencing and File Archive = - 1-313-343-0800, 300/1200/2400/9600 baud, 8/N/1. New users use 'new' - = as a login id. AVAILABLE VIA PC-PURSUIT!!! (City code "MIDET") = E-MAIL Address: dave%tygra@sharkey.cc.umich.edu