X86: Fix the expected size of the immediate offset in MOV_MI.

[gem5.git] / src / arch / x86 / types.hh

diff --git a/src/arch/x86/types.hh b/src/arch/x86/types.hh
index f8a5dbe34678015eceb224b6cab044d36de728f5..6fd36b487d80f2b8c9be736446464a235bde22b3 100644 (file)
--- a/src/arch/x86/types.hh
+++ b/src/arch/x86/types.hh
@@ -58,11 +58,11 @@
 #ifndef __ARCH_X86_TYPES_HH__
 #define __ARCH_X86_TYPES_HH__
 
-#include <inttypes.h>
 #include <iostream>
 
 #include "base/bitunion.hh"
 #include "base/cprintf.hh"
+#include "base/types.hh"
 
 namespace X86ISA
 {
@@ -71,12 +71,12 @@ namespace X86ISA
 
     enum Prefixes {
         NoOverride,
+        ESOverride,
         CSOverride,
+        SSOverride,
         DSOverride,
-        ESOverride,
         FSOverride,
         GSOverride,
-        SSOverride,
         RexPrefix,
         OperandSizeOverride,
         AddressSizeOverride,
@@ -156,8 +156,10 @@ namespace X86ISA
             uint8_t num;
             //The first byte detected in a 2+ byte opcode. Should be 0xF0.
             uint8_t prefixA;
-            //The second byte detected in a 3+ byte opcode. Could be 0xF0 for
-            //3dnow instructions, or 0x38-0x3F for some SSE instructions.
+            //The second byte detected in a 3+ byte opcode. Could be 0x38-0x3F
+            //for some SSE instructions. 3dNow! instructions are handled as
+            //two byte opcodes and then split out further by the immediate
+            //byte.
             uint8_t prefixB;
             //The main opcode byte. The highest addressed byte in the opcode.
             Opcode op;
@@ -175,6 +177,8 @@ namespace X86ISA
         uint8_t addrSize;
         //The effective stack size.
         uint8_t stackSize;
+        //The size of the displacement
+        uint8_t dispSize;
 
         //Mode information
         OperatingMode mode;
@@ -187,12 +191,13 @@ namespace X86ISA
                      "op = {\n\t\tnum = %d,\n\t\top = %#x,\n\t\t"
                            "prefixA = %#x,\n\t\tprefixB = %#x\n\t},\n\t"
                      "modRM = %#x,\n\tsib = %#x,\n\t"
-                     "immediate = %#x,\n\tdisplacement = %#x\n}\n",
+                     "immediate = %#x,\n\tdisplacement = %#x\n\t"
+                     "dispSize = %d}\n",
                      (uint8_t)emi.legacy, (uint8_t)emi.rex,
                      emi.opcode.num, (uint8_t)emi.opcode.op,
                      emi.opcode.prefixA, emi.opcode.prefixB,
                      (uint8_t)emi.modRM, (uint8_t)emi.sib,
-                     emi.immediate, emi.displacement);
+                     emi.immediate, emi.displacement, emi.dispSize);
         return os;
     }
 
@@ -227,37 +232,14 @@ namespace X86ISA
             return false;
         if(emi1.stackSize != emi2.stackSize)
             return false;
+        if(emi1.dispSize != emi2.dispSize)
+            return false;
         return true;
     }
 
-    typedef uint64_t IntReg;
-    //XXX Should this be a 128 bit structure for XMM memory ops?
-    typedef uint64_t LargestRead;
-    typedef uint64_t MiscReg;
-
-    //These floating point types are correct for mmx, but not
-    //technically for x87 (80 bits) or at all for xmm (128 bits)
-    typedef double FloatReg;
-    typedef uint64_t FloatRegBits;
-    typedef union
-    {
-        IntReg intReg;
-        FloatReg fpReg;
-        MiscReg ctrlReg;
-    } AnyReg;
-
-    //XXX This is very hypothetical. X87 instructions would need to
-    //change their "context" constantly. It's also not clear how
-    //this would be handled as far as out of order execution.
-    //Maybe x87 instructions are in order?
-    enum RegContextParam
-    {
-        CONTEXT_X87_TOP
+    struct CoreSpecific {
+        int core_type;
     };
-
-    typedef int RegContextVal;
-
-    typedef uint8_t RegIndex;
 };
 
 #endif // __ARCH_X86_TYPES_HH__