Detecting V86-mode
Jack Ruijs
What might be the easiest way to check whether v86-mode is active from a
normal DOS-program, from 8086 through 80586?
Greetings,
Jack Ruijs
device
running, it's either in real mode, or on a 386+ in v86 mode. here's the
code:
smsw ax
test al,1
jz no_v86_mode
...
no_v86_mode:
...
Note: even though the 286 doesn't support v86 mode, this code will still
run on it with no problems, even though it'd be pointless. But, the
8086 doesn't support any type of protected mode, so the above code would
cause an invalid instruction exception on the "smsw ax".
Dave
David Lindauer
David
Jack Ruijs wrote:
--
---------------------------------------------------------------
David Lindauer mailto:cam...@bluegrass.net ICQ: 8699592
http://www.geocities.com/Area51/Station/5196/index.html (home page)
http://www.geocities.com/Area51/Station/5196/ttc.html (tao te ching)
http://www.geocities.com/Area51/Station/5196/treasure.html (computer page)
wbinvd
| smsw ax
| test al,1
| jz no_v86_mode
| ...
|no_v86_mode:
| ...
|
|Note: even though the 286 doesn't support v86 mode, this code will still
|run on it with no problems, even though it'd be pointless. But, the
|8086 doesn't support any type of protected mode, so the above code would
|cause an invalid instruction exception on the "smsw ax".
Actually not. The 8086 doesn't use exceptions.
black_...@my-dejanews.com
> Note: even though the 286 doesn't support v86 mode, this code will still
> run on it with no problems, even though it'd be pointless. But, the
> 8086 doesn't support any type of protected mode, so the above code would
> cause an invalid instruction exception on the "smsw ax".
The 8086 doesn't have invalid opcode exception; its behaviour is undefined in
this case. 8086 I tested it some time ago just increased IP by 2 and
continued.
It's a lot better to determine CPU time 8086/80186 or above by altering IOPL
field in flags and testing if it changed.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
White Phantom
device wrote:
> 8086 doesn't support any type of protected mode, so the above code would
> cause an invalid instruction exception on the "smsw ax".
There is no such thing on 8086 - Invalid Opcode. That's what will happen on
186.
8086 will skip 2 bytes if it doesn't recognize the opcode.
Thomas Kjørnes
> |Note: even though the 286 doesn't support v86 mode, this code will still
> |run on it with no problems, even though it'd be pointless. But, the
> |8086 doesn't support any type of protected mode, so the above code would
> |cause an invalid instruction exception on the "smsw ax".
>
> Actually not. The 8086 doesn't use exceptions.
Hmm... will it just hang? Or reset itself?
--
Visit my OS theory page @ -= TBD =-
http://home.c2i.net/tkjoerne/os Thomas K.
Michael Tippach
mindspring.com> writes
>well, the 8086 and 80286 do not support v86 mode, so, if your program is
>running, it's either in real mode, or on a 386+ in v86 mode. here's the
>code:
>
> test al,1
> jz no_v86_mode
> ...
>no_v86_mode:
> ...
>
>run on it with no problems, even though it'd be pointless. But, the
>8086 doesn't support any type of protected mode, so the above code would
>cause an invalid instruction exception on the "smsw ax".
Except that the 8086 does not really generate these kinds of exceptions.
It would either ignore invalid opcodes or, like in this case, just
execute what's there:
0F pop cs
; and, if you're lucky:
01E0 add ax, sp
Regards,
Michael Tippach
jpa
(http://developer.intel.com/design/specenvn/intarch/manuals/pentiumr.htm)
(In fact, get all 3 vols, they are very formative)
"
PROCESSOR IDENTIFICATION AND FEATURE DETERMINATION
10.2. IDENTIFICATION OF EARLIER INTEL ARCHITECTURE
PROCESSORS
The CPUID instruction is only available in the Pentium Pro, Pentium, and
recent Intel486
processors. For the earlier Intel Architecture processors (including the
earlier Intel486 proces-sors),
several other architectural features can be exploited to identify the
processor.
The settings of bits 12 and 13 (IOPL), 14 (NT), and 15 (reserved) in the
EFLAGS register (see
Figure 3-7) is different for Intel’s 32-bit processors than for the Intel
8086 and Intel 286 proces-sors.
By examining the settings of these bits (with the PUSHF/PUSHFD and
POP/POPFD
instructions), an application program can determine whether the processor
is an 8086, Intel286,
or one of the Intel 32-bit processors:
• 8086 processor — Bits 12 through 15 of the EFLAGS register are always
set.
• Intel 286 processor — Bits 12 through 15 are always clear in real-address
mode.
• 32-bit processors — In real-address mode, bit 15 is always clear and bits
12 through 14
have the last value loaded into them. In protected mode, bit 15 is always
clear, bit 14 has
the last value loaded into it, and the IOPL bits depends on the current
privilege level (CPL).
The IOPL field can be changed only if the CPL is 0.
Other EFLAG register bits that can be used to differentiate between the
32-bit processors:
• Bit 18 (AC) — Implemented only on the Pentium ® Pro, Pentium, and
Intel486™
processors. The inability to set or clear this bit distinguishes an
Intel386 processor from the
other Intel 32-bit processors.
• Bit 21 (ID) — Determines if the processor is able to execute the CPUID
instruction. The
ability to set and clear this bit indicates that the processor is a Pentium
Pro, Pentium, or
later version Intel486 processor.
To determine whether an FPU or NPX is present in a system, applications can
write to the
FPU/NPX status and control registers using the FNINIT instruction and then
verify the correct
values are read back using the FNSTENV instruction.
After determining that an FPU or NPX is present, its type can then be
determined. In most cases,
the processor type will determine the type of FPU or NPX; however, an
Intel386 processor is
compatible with either an Intel 287 or Intel 387 math coprocessor. The
method the coprocessor
uses to represent ¥ (after the execution of the FINIT, FNINIT, or RESET
instruction) indicates
which coprocessor is present. The Intel 287 math coprocessor uses the same
bit representation
for +¥ and -¥; whereas, the Intel 387 math coprocessor uses different
representations for +¥
and -¥.
"
Jack Ruijs <j.r...@tip.nl> wrote in article
<70gh8s$7vu$1...@autumn.news.rcn.net>...
jpa
This is the correct link:
http://developer.intel.com/design/pro/manuals
sorry about that
jpa <jean-pau...@phoenix.com> wrote in article
<70nj92$d6$1...@autumn.news.rcn.net>...