This is embarassing, I found two bugs in the movd patch of mine that was committed. The first fix possibly can be done with one fewer uop if there is a way to enable zero-extension in the mov2fp instruction.
For the second fix, I don't think that the same fix needs to be made to the memory-based movd, but someone else who knows the uop code better might want to double check. The new code passes my current test-case, but I might be missing some corner cases. Vince # HG changeset patch # User Vince Weaver <[email protected]> # 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 0e5037cecaf7 -r bf7974944442 src/arch/x86/isa/insts/general_purpose/data_transfer/move.py --- a/src/arch/x86/isa/insts/general_purpose/data_transfer/move.py Fri Oct 30 12:49:37 2009 -0400 +++ b/src/arch/x86/isa/insts/general_purpose/data_transfer/move.py Tue Nov 03 13:39:15 2009 -0500 @@ -357,6 +357,7 @@ }; def macroop MOVD_XMM_R { + lfpimm xmml, 0 mov2fp xmml, regm, srcSize=dsz, destSize=dsz lfpimm xmmh, 0 }; @@ -373,7 +374,7 @@ }; def macroop MOVD_R_XMM { - mov2int reg, xmml, size=dsz + mov2int reg, xmmlm, size=dsz }; def macroop MOVD_M_XMM {
movd_vo_ed
Description: Binary data
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
