PC/AT hangs with MOV ax,[ffff] ???
R.v.Kampen
at offset 0ffffh, it will hang,
for instance MOV AX,[ffff] (A1 FF FF when assembled.)
hardware interupts still function (ctrl-alt-del, timer, etc...)
if I try executing it with trace flag on it wont trace past the
instruction.
when changing the 0ffffh to 0fffeh by using a hardware interrupt,
it will continue execution.
neither is an invalid opcode interupt generated.
is this a bug In my processor, or is this 'normal' behaviour??
willem (win...@dutiws.twi.tudelft.nl or it...@hacktic.nl)
--
+------------------------------------------------------------------------------+
| Rob van Kampen Email : win...@dutiws.tudelft.nl |
| Julianalaan 132 phone : +31-15-789999 |
Gary A. Hildebrand
R> On my PC/AT (80286) if I execute a instruction refering to a word
R> at offset 0ffffh, it will hang,
R> for instance MOV AX,[ffff] (A1 FF FF when assembled.)
R> hardware interupts still function (ctrl-alt-del, timer, etc...)
R> if I try executing it with trace flag on it wont trace past the
R> instruction.
R> when changing the 0ffffh to 0fffeh by using a hardware interrupt,
R> it will continue execution.
R> neither is an invalid opcode interupt generated.
R> is this a bug In my processor, or is this 'normal' behaviour??
This is most definitely normal, and not a bug. On a 286 or higher
processor, any attempt to access words on an odd byte boundary near the
segment boundaries (such as offset 1 or FFFFh) will cause a General
Protection exception (the infamous exception 13), which in real mode on
many machines will trigger some halt-like code in the BIOS. Curiously,
word accesses on an even byte boundary will always work, even with segment
wraparound such as could happen with code execution, stack operations, and
string operations. This was *not* the case on the 8086/8088.
Gary
--
/ Gary A. Hildebrand Internet: g...@mew.mei.co.jp \
/ Matsushita Electric Works, Ltd. UUCP: uunet!mew.mei.co.jp!gah \
/ 13-2, Mita 5-chome, Minato-ku Fax: 03-3451-0793 \
/ Tokyo 108, JAPAN Tel: 03-3452-4941 \
Kenneth Kasajian
>willem (win...@dutiws.twi.tudelft.nl or it...@hacktic.nl)
>--
That's the way it's supposed to work.
The only place I've seen this mentioned is in the 80386 guide to the
differences between real mode and virtual 8086 mode. They say that you
can't do the above in virtual 86 mode, but I couldn't get it to work in
real mode, either. oh well.
If you change AX to AL or AH it should work.
Carl Harris
: This is most definitely normal, and not a bug. On a 286 or higher
: processor, any attempt to access words on an odd byte boundary near the
: segment boundaries (such as offset 1 or FFFFh) will cause a General
: Protection exception (the infamous exception 13), which in real mode on
: many machines will trigger some halt-like code in the BIOS.
Doesn't the General Exception Fault use one of the interrupts that IBM
(in their short-sightedness) decided to use for some BIOS function?
Just curious...
--
Carl Harris
ceha...@csugrad.cs.vt.edu
R.v.Kampen
>win...@dutiws.twi.tudelft.nl (R.v.Kampen) writes:
>
>>On my PC/AT (80286) if I execute a instruction refering to a word
>>at offset 0ffffh, it will hang,
>>for instance MOV AX,[ffff] (A1 FF FF when assembled.)
>
>>hardware interupts still function (ctrl-alt-del, timer, etc...)
>>if I try executing it with trace flag on it wont trace past the
>>instruction.
>
>>when changing the 0ffffh to 0fffeh by using a hardware interrupt,
>>it will continue execution.
>
>>neither is an invalid opcode interupt generated.
>
>
>The only place I've seen this mentioned is in the 80386 guide to the
>differences between real mode and virtual 8086 mode. They say that you
>can't do the above in virtual 86 mode, but I couldn't get it to work in
>real mode, either. oh well.
>
interrupt.
>If you change AX to AL or AH it should work.
I stumbled on it when debugging some code where I forgot to increment
DI twice doing XOR [di],ax
It didn't look like code that should hang, to me, different results on
different pc's etc... (Now I figured out what happened)
Gary A. Hildebrand
CH> Doesn't the General Exception Fault use one of the interrupts that IBM
CH> (in their short-sightedness) decided to use for some BIOS function?
Yes. The General Protection exception is mapped to interrupt vector
decimal 13, which is the same as IRQ 5 on IBM-compatibles. For this
reason, protected mode exception handlers which do not depend on the
hardware interrupts being reassigned must determine the source of
invocation of this interrupt vector when it is invoked, usually by
examining a register on the 8295A interrupt controller.
Gary A. Hildebrand
>>>>> "R" == R.v.Kampen <win...@dutiws.twi.tudelft.nl> writes:
R> On my PC/AT (80286) if I execute a instruction refering to a word
R> at offset 0ffffh, it will hang,
R> for instance MOV AX,[ffff] (A1 FF FF when assembled.)
R> hardware interupts still function (ctrl-alt-del, timer, etc...)
R> if I try executing it with trace flag on it wont trace past the
R> instruction.
R> when changing the 0ffffh to 0fffeh by using a hardware interrupt,
R> it will continue execution.
R> neither is an invalid opcode interupt generated.
R> is this a bug In my processor, or is this 'normal' behaviour??
me> This is most definitely normal, and not a bug. On a 286 or higher
me> processor, any attempt to access words on an odd byte boundary near the
me> segment boundaries (such as offset 1 or FFFFh) will cause a General
me> Protection exception (the infamous exception 13), which in real mode on
me> many machines will trigger some halt-like code in the BIOS. Curiously,
me> word accesses on an even byte boundary will always work, even with segment
me> wraparound such as could happen with code execution, stack operations, and
me> string operations. This was *not* the case on the 8086/8088.
To be completely accurate, word accesses on an even byte boundary near the
segment boundaries will always work explicitly, but will work implicitly
only for stack or string operations, and not for code execution.
Furthermore, if a wraparound violation occurs while accessing the stack
segment (using SS), the actual exception is a Stack exception (vector 12
decimal instead of 13). Finally, what I meant about 8086/8088 was that
wraparounds never caused a violation of any kind, although the results
would sometimes be an unwanted side-effect of buggy code!
Gary A. Hildebrand
KK> win...@dutiws.twi.tudelft.nl (R.v.Kampen) writes:
>On my PC/AT (80286) if I execute a instruction refering to a word
>at offset 0ffffh, it will hang,
>for instance MOV AX,[ffff] (A1 FF FF when assembled.)
>hardware interupts still function (ctrl-alt-del, timer, etc...)
>if I try executing it with trace flag on it wont trace past the
>instruction.
>when changing the 0ffffh to 0fffeh by using a hardware interrupt,
>it will continue execution.
>neither is an invalid opcode interupt generated.
>is this a bug In my processor, or is this 'normal' behaviour??
KK> That's the way it's supposed to work.
KK> The only place I've seen this mentioned is in the 80386 guide to the
KK> differences between real mode and virtual 8086 mode. They say that you
KK> can't do the above in virtual 86 mode, but I couldn't get it to work in
KK> real mode, either. oh well.
This "feature" is not one of the differences between real mode and virtual
8086 mode. Both modes will generate the same exception for such a memory
reference. If you are referring to the Intel 386 manual, the wraparound
violation is mentioned under the differences between a *real* 8086/8088 CPU
and the real or virtual 8086 modes of a 386 CPU. Notice that this section
is virtually repeated twice, once for real mode, and a second time for
virtual 8086 mode.
Gary A. Hildebrand
>win...@dutiws.twi.tudelft.nl (R.v.Kampen) writes:
>
>>On my PC/AT (80286) if I execute a instruction refering to a word
>>at offset 0ffffh, it will hang,
>>for instance MOV AX,[ffff] (A1 FF FF when assembled.)
>
>>hardware interupts still function (ctrl-alt-del, timer, etc...)
>>if I try executing it with trace flag on it wont trace past the
>>instruction.
>
>>when changing the 0ffffh to 0fffeh by using a hardware interrupt,
>>it will continue execution.
>
>>neither is an invalid opcode interupt generated.
>
>That's the way it's supposed to work.
>
>The only place I've seen this mentioned is in the 80386 guide to the
>differences between real mode and virtual 8086 mode. They say that you
>can't do the above in virtual 86 mode, but I couldn't get it to work in
>real mode, either. oh well.
>
R> interrupt.
The Invalid Opcode exception uses vector 6 decimal, and is not generated in
the case of segment wraparound violations. Either the General Protection
or the Stack exception (vector 13 or 12 decimal, respectively) is generated
instead.
Christopher Eltschka
I had this problem, too, so I read the articles very interested. Many articles
described the source of it, but no one told, how to avoid this - to remove an
mov ax,[FFFF] is very easy, but it is not easy to debug a pascal program that
uses pointers, if an unknown error sometimes sets an pointer exactly to this
address - especially when watching the value the pointer points to.
(To press the reset button is a very ineffective sport :-) )
Does anyone know how to prevent the computer from hanging?
If there exists no way, this assembler-statement could be added to the 'how to
stop the computer' - discussion, which was not long ago (I don't remember, if it
was in this newsgroup)