On Tue, 3 Nov 2009, Gabe Black wrote:
> If you set destSize=8 I think that'll solve the first problem. The
> source register is put into a uint64_t, and then that's put into a
> destSize sized chunk of the destination register. If you set that to be
> 8, the uint64_t will take up the whole xmml, and the uint64_t is zero
> extended. The second bug is genuine and I believe your patch fixes it.
I've tested the following patch with your suggested change and it
passes my test cases. Does this look good enough to commit?
Vince
# HG changeset patch
# User Vince Weaver <vi...@csl.cornell.edu>
# Date 1257273555 18000
# Node ID bf7974944442f919d01fd112f79171affb86aeb1
# Parent 0e5037cecaf776e18a6be727981a33144f4bde64
Fix bugs in X86 movd implementation.
Unfortunately my implementation of the movd instruction had two bugs.
In one case, when moving a 32-bit value into an xmm register, the
lower half of the xmm register was not zero extended.
The other case is that xmm was used instead of xmmlm as the source
for a register move. My test case didn't notice this at first
as it moved xmm0 to eax, both with apparently have the same register
number.
diff -r 2e67bb7c9b4c
src/arch/x86/isa/insts/general_purpose/data_transfer/move.py
--- a/src/arch/x86/isa/insts/general_purpose/data_transfer/move.py Mon Nov
09 10:02:55 2009 -0500
+++ b/src/arch/x86/isa/insts/general_purpose/data_transfer/move.py Mon Nov
09 19:27:34 2009 -0500
@@ -357,7 +357,7 @@
};
def macroop MOVD_XMM_R {
- mov2fp xmml, regm, srcSize=dsz, destSize=dsz
+ mov2fp xmml, regm, srcSize=dsz, destSize=8
lfpimm xmmh, 0
};
@@ -373,7 +373,7 @@
};
def macroop MOVD_R_XMM {
- mov2int reg, xmml, size=dsz
+ mov2int reg, xmmlm, size=dsz
};
def macroop MOVD_M_XMM {
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
