Trixter
Veteran Member
I stumbled onto the 8086-80286 "only the two most recent prefixes are honored after an interrupt" bug doing something visual and could reproduce it, so I thought I'd make a short video about it:
@@again:
seges movsb
loop @@again
cli
es: rep movsb
sti
mov bp,ds
mov bx,es
mov ds,bx
rep movsb
mov ds,bp
push ds
push es
pop ds
rep movsb
pop ds
shr cx,1
rep movsw
adc cx,cx
rep movsb
Does (movsb) rep movsw gain anything in this case?
The size-optimized fix was:
Code:@@again: seges movsb loop @@again
@@again:
seges movsb
inc cx
loop @@again
When I timed the code with varying input, this:
Code:cli es: rep movsb sti
This will lead to an off-by-one error for every interrupt(ion). All the workarounds I've seen return to the string instruction with CX unchanged.
rep movsw is the reason that the Lo-tech storage adapters are able to perform better that other types. But not all early hardware correctly implements the byte transfer order (AT&T PC6300 I think was one).
Are you sure?
Note that this code does not use the 'rep' prefix at all. It uses loop *instead* of rep, therefore the issue does not exist.
I'd call it a "documented bug" especially since they "fixed" it on later processors.
Did you test and verify whether the 286 has the bug or not?
There are still no results.Ah yes, I have a 286 as well of course (a late model Harris 286-20). I could do a little test myself if I get round to it.
So the described behaviors don't guarantee the correct execution of the sequence of two prefixes too.During the execution of a repeated primitive operation the operand pointer registers (SI and DI) and the operation count register (CX) are updated after each repetition, whereas the instruction pointer will retain the offset address of the repeat prefix byte (assuming it immediately precedes the string operation instruction). Thus, an interrupted repeated operation will be correctly resumed when control returns from the interrupting task.