headers
Gwenole Beauchesne | 1 Dec 2003 07:51
Favicon

Re: IMUL eflags update

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"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johan Rydberg | 1 Dec 2003 09:24

Re: IMUL eflags update


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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charlie Gordon | 1 Dec 2003 10:38
Picon
Favicon

Re: IMUL eflags update

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 <at> free.fr>
To: <qemu-devel <at> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gwenole Beauchesne | 2 Dec 2003 16:13
Favicon

PowerPC CPU tester

Hi,

I have finally glued QEMU to my test engine. Extra patches to QEMU core
are appended below.

You can find the files here:
<http://gwenole.beauchesne.free.fr/kheperix/>
* test-powerpc.cpp
* kheperix-0.2-ppc-results.dat.bz2: results file for non PPC platforms

The tester is old but covers around 690K variations (1.3M nowadays):
154656 errors out of 689408 tests

Most of them are due to miscalculation of the overflow flag. "neg" is 
probably mis-decoded thus not handling CR or XER updates. Should be pretty 
simple to fix.

Hope this helps.

Index: cpu-all.h
===================================================================
RCS file: /cvsroot/qemu/qemu/cpu-all.h,v
retrieving revision 1.14
diff -u -r1.14 cpu-all.h
--- cpu-all.h	23 Nov 2003 17:05:30 -0000	1.14
+++ cpu-all.h	2 Dec 2003 14:50:19 -0000
 <at>  <at>  -213,7 +213,7  <at>  <at> 
 {
     uint32_t a,b;
     a = ldl_raw(ptr);
(Continue reading)

Permalink | Reply | 3 comments |
headers
Fabrice Bellard | 2 Dec 2003 22:59
Picon
Favicon

qemu/target-i386 helper2.c

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Branch: 	
Changes by:	Fabrice Bellard <fabrice.bellard <at> free.fr>	03/12/02 16:59:22

Modified files:
	target-i386    : helper2.c 

Log message:
	dump irq inhibit flag as it is a part of the cpu state

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/target-i386/helper2.c.diff?tr1=1.6&tr2=1.7&r1=text&r2=text
Permalink | Reply | 0 comments |
headers
Fabrice Bellard | 2 Dec 2003 23:01
Picon
Favicon

qemu/target-i386 cpu.h op.c ops_template.h tran...

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Branch: 	
Changes by:	Fabrice Bellard <fabrice.bellard <at> free.fr>	03/12/02 17:01:31

Modified files:
	target-i386    : cpu.h op.c ops_template.h translate.c 

Log message:
	P4 style multiplication eflags

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/target-i386/cpu.h.diff?tr1=1.3&tr2=1.4&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/target-i386/op.c.diff?tr1=1.7&tr2=1.8&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/target-i386/ops_template.h.diff?tr1=1.2&tr2=1.3&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/target-i386/translate.c.diff?tr1=1.9&tr2=1.10&r1=text&r2=text
Permalink | Reply | 0 comments |
headers
Fabrice Bellard | 2 Dec 2003 22:55
Picon
Favicon

qemu/tests test-i386.c

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Branch: 	
Changes by:	Fabrice Bellard <fabrice.bellard <at> free.fr>	03/12/02 16:55:34

Modified files:
	tests          : test-i386.c 

Log message:
	more complete eflags testing for multiplication (P4 case only)

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/tests/test-i386.c.diff?tr1=1.29&tr2=1.30&r1=text&r2=text
Permalink | Reply | 0 comments |
headers
Fabrice Bellard | 2 Dec 2003 23:18
Picon
Favicon

qemu vl.c

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Branch: 	
Changes by:	Fabrice Bellard <fabrice.bellard <at> free.fr>	03/12/02 17:18:11

Modified files:
	.              : vl.c 

Log message:
	disable keyboard interrupts if keyboard clock disabled (may not be fully correct) - added keyboard ID for
extended keyboard

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/vl.c.diff?tr1=1.33&tr2=1.34&r1=text&r2=text
Permalink | Reply | 0 comments |
headers
J. Mayer | 2 Dec 2003 23:44
Picon
Favicon

Re: PowerPC CPU tester

On Tue, 2003-12-02 at 16:13, Gwenole Beauchesne wrote:
> Hi,
> 
> I have finally glued QEMU to my test engine. Extra patches to QEMU core
> are appended below.
> 
> You can find the files here:
> <http://gwenole.beauchesne.free.fr/kheperix/>
> * test-powerpc.cpp
> * kheperix-0.2-ppc-results.dat.bz2: results file for non PPC platforms
> 
> The tester is old but covers around 690K variations (1.3M nowadays):
> 154656 errors out of 689408 tests
> 
> Most of them are due to miscalculation of the overflow flag. "neg" is 
> probably mis-decoded thus not handling CR or XER updates. Should be pretty 
> simple to fix.
>
Hi, 

Thanks for testing.
I'm surprised that you have problems with standard arithmetics and
logical tests, as I did test a lot of cases with my ppc-test programs
which gives the same result on a real PPC (G3 & G4) and under qemu.
Would it be possible to get a readable description of the problems
encountered ?
I can do nothing of you .dat file.
I also pass the U-boot cpu post test, 
with some fixes for string load/store and
rlwmi instructions.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gwenole Beauchesne | 3 Dec 2003 08:10
Favicon

Re: PowerPC CPU tester

Hi,

> Would it be possible to get a readable description of the problems
> encountered ?

Hmm, wait, I read XER the wrong way. It seems you used the normal 
numbering way with 0 being LSB. I have uploaded a new version of 
test-powerpc.cpp. Sorry, for the inconvience. Only "rlwimi" were wrong 
indeed.
30698 errors out of 689408 tests

>> Testing neg
>> invalid bits: 00002800 for opcode: 1f -08 - 03 (0x7c6428d0) 
>> (0x80031890)
> According to PPC specification, bits 16 to 20 (in IBM/Motorola 
> notation) have
> always to be zero, has neg have no rB operand.

Indeed, copy-paste propagation. ;-) Thanks, for noticing.

>> +#ifdef DO_EXEC_RETURN
>> +		if (ctx.opcode == 0x18000000) {
>> +		  gen_op_raise_exception(EXCP_HLT);
>> +		  break;
>> +		}
>> +#endif
>>          /* Is opcode *REALLY* valid ? */
>>          if ((ctx.opcode & handler->inval) != 0) {
>>              if (loglevel > 0) {
>>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane