[Qemu-devel] IMUL eflags update

[Qemu-devel] IMUL eflags update

[Fabrice Bellard]

Hi,

My next patches will allow Windows 3.11 to be usable in QEMU. While 
fixing a bug related to the cursor drawing, I found an interesting 
problem related to x86 processors:

Which x86 condition codes get updated by the mul/imul instructions ?

The intel specs says that only CF and OF are updated. The other 
condition codes are said to be undefined. The problem is that the 
Windows 3.11 cursor drawing code relies on the "SF" flag after imul 
(here is the offending code disassembled with Bochs):

0002866d: (                    ): mov AX, DS:[BX+0169]      ; 8b876901
00028671: (                    ): mov CX, DS:[BP+0165]      ; 3e8b8e6501
00028676: (                    ): sub AX, CX                ; 2bc1
00028678: (                    ): mov DL, AL                ; 8ad0
0002867a: (                    ): imul AX, AX, 05           ; 6bc005
0002867d: (                    ): jl 8685                   ; 7c06
0002867f: (                    ): add DI, AX                ; 03f8
00028681: (                    ): neg DL                    ; f6da
00028683: (                    ): jmp 8687                  ; eb02
00028685: (                    ): sub SI, AX                ; 2bf0
00028687: (                    ): add DL, 20                ; 80c220

The solution used by Bochs to fix the problem is to say that imul 
modifies only OF and CF. The other flas are not modified.

QEMU currently zeros all the other flags in order to have a faster flag 
update.

By doing tests on a Pentium 4 processor, it seems that at least SF is 
set according to the result of the IMUL operation.

So what is the best behavior to implement ? Bochs one or P4 one ?

Fabrice.

Re: [Qemu-devel] IMUL eflags update

[Gwenole Beauchesne]

Hi,

> So what is the best behavior to implement ? Bochs one or P4 one ?

I would say implement the P4 one since you have an instance of that  
sort of use.

BTW, P4 seems to have changed flags behavior of some other instructions  
too, even though the spec says they are undefined. They now are. I  
didn't know for IMUL but BSF instead. For Basilisk II m68k JIT  
compiler, I am detecting that as follows:

<http://down.physik.uni-mainz.de/cgi-bin/viewcvs.cgi/BasiliskII/src/ 
uae_cpu/compiler/codegen_x86.cpp.diff?r1=1.9&r2=1.10>
(BSF used to preserve flags thus permitting fast setting of the Z flag  
only)

static bool target_check_bsf(void)
{
         bool mismatch = false;
         for (int g_ZF = 0; g_ZF <= 1; g_ZF++) {
         for (int g_CF = 0; g_CF <= 1; g_CF++) {
         for (int g_OF = 0; g_OF <= 1; g_OF++) {
         for (int g_SF = 0; g_SF <= 1; g_SF++) {
                 for (int value = -1; value <= 1; value++) {
                         int flags = (g_SF << 7) | (g_OF << 11) | (g_ZF  
<< 6) | g_CF;
                         int tmp = value;
                         __asm__ __volatile__ ("push %0; popf; bsf  
%1,%1; pushf; pop %0"
                                                                   :  
"+r" (flags), "+r" (tmp) : : "cc");
                         int OF = (flags >> 11) & 1;
                         int SF = (flags >>  7) & 1;
                         int ZF = (flags >>  6) & 1;
                         int CF = flags & 1;
                         tmp = (value == 0);
                         if (ZF != tmp || SF != g_SF || OF != g_OF || CF  
!= g_CF)
                                 mismatch = true;
                 }
         }}}}
         if (mismatch)
                 write_log("Target CPU defines all flags on BSF  
instruction\n");
         return !mismatch;
}

Re: [Qemu-devel] IMUL eflags update

[Johan Rydberg]

On Mon, 1 Dec 2003, Fabrice Bellard wrote:

: The solution used by Bochs to fix the problem is to say that imul
: modifies only OF and CF. The other flas are not modified.
:
: QEMU currently zeros all the other flags in order to have a faster flag
: update.
:
: By doing tests on a Pentium 4 processor, it seems that at least SF is
: set according to the result of the IMUL operation.
:
: So what is the best behavior to implement ? Bochs one or P4 one ?

The question is; do we want a working emulator, or a accurate emulator?

I rather see the latter, since adding workarounds for buggy software
will only endorce more buggy software.  People using QEMU for
developing operating systems might take for granted that the SF flag
will be modified by the mul/imul insns.

I could not care less [1] if Windows 3.11 can be booted in QEMU .

brgds
johan

 [1] From my point of view, supporting non-free software such as
     Microsoft products only promote them.  Instead we should
     promote free software.

Re: [Qemu-devel] IMUL eflags update

[Charlie Gordon]

Hi fellow,

There are multiple forms of the IMUL instruction.  I suspect they do not
behave identically with regard to (unspecified) flags update.
Extensive testing on different CPUs (486, pentiums, AMDs, Cyrix...) should
tell you what is the precise behaviour.  Common patterns should emerge and
should be emulated as compatible OSes might rely on them.  Testing on a
TransMeta chip would be interesting too!
Bochs approach seems quite pragmatic, do they document or can they be
questioned as to why they decided for flags preservation.

Charlie Gordon.

----- Original Message -----
From: "Fabrice Bellard" <fabrice.bellard@free.fr>
To: <qemu-devel@nongnu.org>
Sent: Monday, December 01, 2003 12:15 AM
Subject: [Qemu-devel] IMUL eflags update


> Hi,
>
> My next patches will allow Windows 3.11 to be usable in QEMU. While
> fixing a bug related to the cursor drawing, I found an interesting
> problem related to x86 processors:
>
> Which x86 condition codes get updated by the mul/imul instructions ?
>
> The intel specs says that only CF and OF are updated. The other
> condition codes are said to be undefined. The problem is that the
> Windows 3.11 cursor drawing code relies on the "SF" flag after imul
> (here is the offending code disassembled with Bochs):
>
> 0002866d: (                    ): mov AX, DS:[BX+0169]      ; 8b876901
> 00028671: (                    ): mov CX, DS:[BP+0165]      ; 3e8b8e6501
> 00028676: (                    ): sub AX, CX                ; 2bc1
> 00028678: (                    ): mov DL, AL                ; 8ad0
> 0002867a: (                    ): imul AX, AX, 05           ; 6bc005
> 0002867d: (                    ): jl 8685                   ; 7c06
> 0002867f: (                    ): add DI, AX                ; 03f8
> 00028681: (                    ): neg DL                    ; f6da
> 00028683: (                    ): jmp 8687                  ; eb02
> 00028685: (                    ): sub SI, AX                ; 2bf0
> 00028687: (                    ): add DL, 20                ; 80c220
>
> The solution used by Bochs to fix the problem is to say that imul
> modifies only OF and CF. The other flas are not modified.
>
> QEMU currently zeros all the other flags in order to have a faster flag
> update.
>
> By doing tests on a Pentium 4 processor, it seems that at least SF is
> set according to the result of the IMUL operation.
>
> So what is the best behavior to implement ? Bochs one or P4 one ?
>
> Fabrice.
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
>