summaryrefslogtreecommitdiff
path: root/src/arch/x86/isa/decoder/decoder.isa
AgeCommit message (Collapse)Author
2017-05-26x86: Rework how VEX prefixes are decoded.Gabe Black
Remove redundant information from the ExtMachInst, hash the vex information to ensure the decode cache works properly, print the vex info when printing an ExtMachInst, consider the vex info when comparing two ExtMachInsts, fold the info from the vex prefixes into existing settings, remove redundant decode code, handle vex prefixes one byte at a time and don't bother building up the entire prefix, and let instructions that care about vex use it in their implementation, instead of developing an entire parallel decode tree. This also eliminates the error prone vex immediate decode table which was incomplete and would result in an out of bounds access for incorrectly encoded instructions or when the CPU was mispeculating, as it was (as far as I can tell) redundant with the tables that already existed for two and three byte opcodes. There were differences, but I think those may have been mistakes based on the documentation I found. Also, in 32 bit mode, the VEX prefixes might actually be LDS or LES instructions which are still legal in that mode. A valid VEX prefix would look like an LDS/LES with an otherwise invalid modrm encoding, so use that as a signal to abort processing the VEX and turn the instruction into an LES/LDS as appropriate. Change-Id: Icb367eaaa35590692df1c98862f315da4c139f5c Reviewed-on: https://gem5-review.googlesource.com/3501 Reviewed-by: Joe Gross <joe.gross@amd.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
2015-07-17x86: decode instructions with vex prefixNilay Vaish
This patch updates the x86 decoder so that it can decode instructions with vex prefix. It also updates the isa with opcodes from vex opcode maps 1, 2 and 3. Note that none of the instructions have been implemented yet. The implementations would be provided in due course of time.
2014-12-04x86: Rework opcode parsing to support 3 byte opcodes properly.Gabe Black
Instead of counting the number of opcode bytes in an instruction and recording each byte before the actual opcode, we can represent the path we took to get to the actual opcode byte by using a type code. That has a couple of advantages. First, we can disambiguate the properties of opcodes of the same length which have different properties. Second, it reduces the amount of data stored in an ExtMachInst, making them slightly easier/faster to create and process. This also adds some flexibility as far as how different types of opcodes are handled, which might come in handy if we decide to support VEX or XOP instructions. This change also adds tables to support properly decoding 3 byte opcodes. Before we would fall off the end of some arrays, on top of the ambiguity described above. This change doesn't measureably affect performance on the twolf benchmark. --HG-- rename : src/arch/x86/isa/decoder/three_byte_opcodes.isa => src/arch/x86/isa/decoder/three_byte_0f38_opcodes.isa rename : src/arch/x86/isa/decoder/three_byte_opcodes.isa => src/arch/x86/isa/decoder/three_byte_0f3a_opcodes.isa
2010-05-23copyright: Change HP copyright on x86 code to be more friendlyNathan Binkert
2009-08-18X86: Decode three byte opcodes.Gabe Black
2009-04-19X86: Recognize and handle the lock legacy prefix.Gabe Black
2007-03-21Break out the one and two byte opcodes into different files. Also change ↵Gabe Black
what bits decode is done on to reflect where clumps of instructions are. --HG-- extra : convert_revision : 8768676eac25e6a4f0dc50ce2dc576bdcdd6e025
2007-03-21Missed a constGabe Black
--HG-- rename : src/arch/x86/isa/decoder.isa => src/arch/x86/isa/decoder/decoder.isa extra : convert_revision : a60e7495da6fe99fa2375a3f801f2962c3e41adb