REP MOVS not Interrupt Safe? 
Author Message
 REP MOVS not Interrupt Safe?

Dear x86 experts,

I recently heard a rumor that REP MOVS can fail to complete all iterations if
it is interrupted by a hardware interrupt, and the ISR also uses a REP prefix
in its code. The code in question does not use any prefixes other than a
single REP and the code does make sure that the direction flag is set
correctly.

Can anyone confirm that such a bug exists in any 386 compatible CPU? I tried
to reproduce it on a 386SX, but my code never fails (at least not within the
first 1 million interrupts I tried).

Peter



Tue, 10 Jul 2001 03:00:00 GMT  
 REP MOVS not Interrupt Safe?

Quote:

> I recently heard a rumor that REP MOVS can fail to complete all iterations if
> it is interrupted by a hardware interrupt, and the ISR also uses a REP prefix
> in its code. The code in question does not use any prefixes other than a
> single REP and the code does make sure that the direction flag is set
> correctly.
> Can anyone confirm that such a bug exists in any 386 compatible CPU?

  Lots of code would be broken if that were true.  I don't think
there is any basis for it.

  There is a documented flaw in the 8086/8088 that if you interrupt
a rep instruction that has another prefix (segment override) then
on exit from the ISR only the last prefix is recognised and the
instruction continues incorrectly.  This can't be what you mean
because:

1)  It requires another prefix.  You said there wasn't one.
2)  It doesn't matter whether the ISR uses REP or not.
3)  It doesn't malfunction on a 386.
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/



Tue, 10 Jul 2001 03:00:00 GMT  
 REP MOVS not Interrupt Safe?
Let's have a look at Ralph Brown's Interrupt List - file 86BUGS.LST

Michael

MOVS  Move string of bytes, words or doublewords in memory
??????????????????????????????????????????????????????????????????????????????

Mnemonic: MOVSB / MOVSW / MOVSD
Opcode  : A4    / A5    / 66 A5
Bug in  : early 286 in PM, some 386

Function:
MOVS moves strings in memory. Possible units to move are byte, word and
doubleword. Typically the source is DS:(E)SI, the target ES:(E)DI

If the single instruction MOVS (not prefixed by REPx) is executed with a
NULL selector in ES or when ES:DI points beyond the segment limit while
executing the the single instruction, causing exception 0dh, the CS:IP
saved by the 0dh exception handler will point after the MOVS
instruction,
instead of to it on some 286s.

If a segment limit exception or IOPL violation exception occurs during
the
REPx prefixed form of MOVS in Protected Mode, some early 286 will reset
CX
to its initial setting (before the REPx started) instead of showing CX
as
it was at the time of the exception. SI and DI are not affected and show
the
values they had at the time of the exception.

During debugging with breakpoints set, REP MOVS can cause data
breakpoints
to be missed on some 386, see <debugging>.

If, on some 386es, MOVS is followed by an instruction which uses a
different
address size, or by an instruction which implicitly references the stack
(like POP, PUSH, IRET, RET, CALL, ENTER, LEAVE, PUSHA, POPA, PUSHF and
POPF)
while the D-bit for the stack is different from the current address size
used by the MOVS instruction, the destination register updated will
depend
on the address size of the instruction that follows, rather than that of
the MOVS. This can result in the updating of only DI when EDI was meant
or EDI when only DI was meant.

The repeated form REPx MOVS has the same bug, but in addition to (E)DI,
also (E)SI is affected.

A workaround is to always code a NOP with the same address size after
MOVS
and REPx MOVS.

Example:

    (16-bit code segment)
    MOVSW       ; 16-bit addressing MOVS
    NOP         ; 16-bit addressing NOP
    db 67h
    MOVSW       ; 32-bit addressing MOVS
    db 67h
    NOP         ; 32-bit addressing NOP

    (32-bit code segment)
    MOVSD       ; 32-bit addressing MOVS
    NOP         ; 32-bit addressing NOP
    db 67h
    MOVSD       ; 16-bit addressing MOVS
    db 67h
    NOP         ; 16-bit addressing NOP

Peter Petersen schrieb:

Quote:

> Dear x86 experts,

> I recently heard a rumor that REP MOVS can fail to complete all iterations if
> it is interrupted by a hardware interrupt, and the ISR also uses a REP prefix
> in its code. The code in question does not use any prefixes other than a
> single REP and the code does make sure that the direction flag is set
> correctly.

> Can anyone confirm that such a bug exists in any 386 compatible CPU? I tried
> to reproduce it on a 386SX, but my code never fails (at least not within the
> first 1 million interrupts I tried).

> Peter



Wed, 11 Jul 2001 03:00:00 GMT  
 REP MOVS not Interrupt Safe?
John

Quote:
>  Lots of code would be broken if that were true.  I don't think
>there is any basis for it.

Thanks for your reply. Since nobody here confirms this bug, I will assume the
rumor is wrong. Indeed, if it were true, no system which allows hardware
interrupts could work properly with today's common implementations of
memcpy(), memset(), etc. Just think how often this bug would hit any
preemptive multitasking system.

Peter



Wed, 11 Jul 2001 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Segment boundary and the REP MOVS byte block move

2. Problem with interrupt entry and rep.clauses in GNAT

3. PM Programming: Interrupts not interrupting

4. i386: rep movsd vs. rep movsb

5. Syntax of REP INSW and REP OUTSW???

6. String rep freed before internal rep.

7. Eiffel not type safe??

8. class variables not thread-safe?

9. code showing Array not thread safe?

10. not safe at all

11. import not thread safe?

12. cPickle UnPicklingError module not safe for unpickling

 

 
Powered by phpBB® Forum Software