A big bug inside 80386 , did anyone find that ? 
Author Message
 A big bug inside 80386 , did anyone find that ?

The 80386DX and 80386SX both have a bug , guess the final value of
AX register:

 cli                         ; disable all interrupts
mov ax,1234h     ; loaded AX with any nonzero value
 pusha                   ; push the value on to the stack use push all

 popa                     ; then pop back again
 mov bl,[bx+si]    ;  base-index addressing mode
 sti                         ;

  If the piece of code excuted on a 80386 DX or SX, the AX register
value will be ZERO, but on 80486 it will be 1234h.
 First time I thought the 80386 in my PC is dead, but today I try on
another PC and I find the behavier is same.
Did any one find that ?    

------------------------------------------

------------------------------------------



Mon, 26 Apr 1999 03:00:00 GMT  
 A big bug inside 80386 , did anyone find that ?

: The 80386DX and 80386SX both have a bug , guess the final value of
: AX register:

:  cli                         ; disable all interrupts
: mov ax,1234h     ; loaded AX with any nonzero value
:  pusha                   ; push the value on to the stack use push all

:  popa                     ; then pop back again
:  mov bl,[bx+si]    ;  base-index addressing mode
:  sti                         ;

:   If the piece of code excuted on a 80386 DX or SX, the AX register
: value will be ZERO, but on 80486 it will be 1234h.
:  First time I thought the 80386 in my PC is dead, but today I try on
: another PC and I find the behavier is same.
: Did any one find that ?    

It's a documented bug.  The following is from Hamarsoft's 86BUGS list,
(C) 1993/94 By Hamarsoft (R)

POPA / POPAD Pop all general purpose registers

Mnemonic: POPA / POPAD
Opcode  : 61 / 66 61
Bug in  : some 386

Function:
POPA and POPAD pop all general purpose registers from the stack.
POPA pops 16-bit registers and POPAD pops 32-bit registers. The opcode is
the same. POPAD is POPA with an operand size prefix (66h).

If either POPA or POPAD is followed by an instruction which uses an
effective address calculation consisting of a base register and another
register other than (E)AX as an index, the contents of EAX is corrupted.

Also, if POPA or POPAD in 16-bit mode is followed by an instruction which
uses an effective address using EAX as a base or index, the CPU will hang.

The workaround is to always code a NOP after POPA as well as POPAD.

; End of extract

Hope this helped.
Kim



Tue, 27 Apr 1999 03:00:00 GMT  
 A big bug inside 80386 , did anyone find that ?

Quote:

>The 80386DX and 80386SX both have a bug , guess the final value of
>AX register:

> cli                         ; disable all interrupts
>mov ax,1234h     ; loaded AX with any nonzero value
> pusha                   ; push the value on to the stack use push all

> popa                     ; then pop back again
> mov bl,[bx+si]    ;  base-index addressing mode
> sti                         ;

>  If the piece of code excuted on a 80386 DX or SX, the AX register
>value will be ZERO, but on 80486 it will be 1234h.
> First time I thought the 80386 in my PC is dead, but today I try on
>another PC and I find the behavier is same.
>Did any one find that ?    

My AMD 386DX seems to have the bug. The relevant part there is the
indexing followed by popa, adding a nop in between fixes it.

Osmo



Tue, 27 Apr 1999 03:00:00 GMT  
 A big bug inside 80386 , did anyone find that ?



Hi there,

Quote:
> cli                         ; disable all interrupts
> mov ax,1234h     ; loaded AX with any nonzero value
> pusha                   ; push the value on to the stack use push all

> popa                     ; then pop back again
> mov bl,[bx+si]    ;  base-index addressing mode
> sti                         ;

I tried this out with MSDOS debug in tracemodus and everything was correct!

Niko ;-)+

--------------------------------------------------------------------

www.inx.de/~nkomin (sorry, only available in german)
www.inx.de/~nkomin/html/assembe.htm (assemblypage - english!)



Tue, 27 Apr 1999 03:00:00 GMT  
 A big bug inside 80386 , did anyone find that ?

Hello S.C.Lai,

Quote:
> The 80386DX and 80386SX both have a bug, guess the final value of AX
> register:
>  cli                         ; disable all interrupts
>  mov ax,1234h                ; loaded AX with any nonzero value
>  pusha                       ; push the value on to the stack use push all
>  popa                        ; then pop back again
>  mov bl,[bx+si]              ;  base-index addressing mode
>  sti                         ;
> If the piece of code excuted on a 80386 DX or SX, the AX register value
> will be ZERO, but on 80486 it will be 1234h. First time I thought the
> 80386 in my PC is dead, but today I try on another PC and I find the
> behavier is same. Did any one find that ?

Please, refer to

http://support.intel.com/oem_developer/embedded_ia/386/general/386SX-...

for a list of known i80386 processor errata. Although the list is neither
complete, nor up-to-date, a problem with POPA is described there (see the
text below). Although this instruction following POPA in your code is NOT
using EAX as a base, it still COULD be related to that erratum. Please do
check whether a NOP after POPA (as suggested below) makes this problem go
away. Okay, here comes Intel's erratum:

-------------------------------------------------------------------------

Problem: The 386 SX CPU inadvertently corrupts the EAX register when either
the POPA or POPAD instruction is followed by an instruction that uses the
EAX register as a base address register AND is using an additional register
as an index register. This sequence of code appears as:

 POPA/POPAD
 <instr> REG, <data size> ptr [EAX + <Index Reg>]

The following sample code is an example of the program:

 MOV EAX, 4
 POPAD
 MOV EBX, dword ptr [EAX + EBX*4]

Implications
If the above instruction sequence occurs, the EAX register will contain an
undefined value. Proper operation of the processor cannot be guaranteed after
this sequence is executed until a hardware reset occurs. This sequence of
instructions can occur in the Real, Protected and Virtual 86 modes of the
386 SX CPU.

Suggested Workaround
Never execute the described instruction sequence. A workaround which has been
proven to be successful in all cases is to insert a NOP instruction after every
POPAD instruction; an example is shown below:

 MOV EAX, 4
 POPA/POPAD
 NOP
 MOV EBX, dword ptr [EAX + EBX*4]

-------------------------------------------------------------------------

--
Christian Ludloff       [Intel's log, stardate 10/30/1994] We are Pentium (TM)

Speaking for myself.    Any trademark is the property of the respective owner.



Wed, 28 Apr 1999 03:00:00 GMT  
 A big bug inside 80386 , did anyone find that ?


Quote:



>Hi there,

>> cli                         ; disable all interrupts
>> mov ax,1234h     ; loaded AX with any nonzero value
>> pusha                   ; push the value on to the stack use push all

>> popa                     ; then pop back again
>> mov bl,[bx+si]    ;  base-index addressing mode
>> sti                         ;

>I tried this out with MSDOS debug in tracemodus and everything was correct!

Whether the bug appears during trace is not relevant.

Osmo



Thu, 29 Apr 1999 03:00:00 GMT  
 A big bug inside 80386 , did anyone find that ?

Quote:

>The 80386DX and 80386SX both have a bug , guess the final value of
>AX register:

> cli                         ; disable all interrupts
>mov ax,1234h     ; loaded AX with any nonzero value
> pusha                   ; push the value on to the stack use push all

> popa                     ; then pop back again
> mov bl,[bx+si]    ;  base-index addressing mode
> sti                         ;

>  If the piece of code excuted on a 80386 DX or SX, the AX register
>value will be ZERO, but on 80486 it will be 1234h.
> First time I thought the 80386 in my PC is dead, but today I try on
>another PC and I find the behavier is same.
>Did any one find that ?    

This is well known, it's called the "POPAD bug"

------------------------------------------------------------------------

 FREELIB:  ftp://ftp.simtel.net/pub/simtelnet/msdos/a{*filter*}l/freeli22.zip
 Snippets: ftp://ftp.simtel.net/pub/simtelnet/msdos/a{*filter*}l/asnip11.zip
------------------------------------------------------------------------



Thu, 29 Apr 1999 03:00:00 GMT  
 A big bug inside 80386 , did anyone find that ?

Quote:

>The 80386DX and 80386SX both have a bug , guess the final value of
>AX register:
> cli                         ; disable all interrupts
>mov ax,1234h     ; loaded AX with any nonzero value
> pusha                   ; push the value on to the stack use push all
> popa                     ; then pop back again
> mov bl,[bx+si]    ;  base-index addressing mode
> sti                         ;
>  If the piece of code excuted on a 80386 DX or SX, the AX register
>value will be ZERO, but on 80486 it will be 1234h.
> First time I thought the 80386 in my PC is dead, but today I try on
>another PC and I find the behavier is same.
>Did any one find that ?    

Yeah, it's a well known bug. A lot of compilers used to insert a NOP in
between the POPA and the next MOV instruction, just to avoid this bug, if
they were 386-aware. You'll likely find it most compilers to this day too.

                                        Yousuf Khan
--
Yousuf J. Khan

Ottawa, Ont, Canada
Nation's capital



Thu, 29 Apr 1999 03:00:00 GMT  
 A big bug inside 80386 , did anyone find that ?

Quote:

>I tried this out with MSDOS debug in tracemodus and everything was correct!
>Niko ;-)+

Try it without stepping through the code. Just set it up so that the code
stops at the end of the MOV instruction, and you'll see that the behaviour
is exhibited. Single-stepping actually prevents the bug from showing up.

                                        Yousuf Khan
--
Yousuf J. Khan

Ottawa, Ont, Canada
Nation's capital



Thu, 29 Apr 1999 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Where to find a scheme-interpreter for PCs, 80386

2. More 80386/80486 bugs?!?!

3. A Bug found in VX-REXX - Big woopteedo.

4. Anyone else find this bug?

5. Intel 80386 Assembly Group

6. 32-Bit Forth For 80386+

7. 32-bit forth for 80386+

8. 32 bit Forth for 80386+

9. 80386 32-bit FORTH

10. 80386 32-bit FORTH

11. 80386 32-bit Forth

12. Forth on the Intel 80386

 

 
Powered by phpBB® Forum Software