Searched hist:12045 (Results 1 - 8 of 8) sorted by relevance
/gem5/src/arch/x86/ | ||
H A D | decoder_tables.cc | diff 12045:31d9a81ba286 Wed May 24 06:09:00 EDT 2017 Gabe Black <gabeblack@google.com> x86: Rework how VEX prefixes are decoded. 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> |
H A D | decoder.cc | diff 12045:31d9a81ba286 Wed May 24 06:09:00 EDT 2017 Gabe Black <gabeblack@google.com> x86: Rework how VEX prefixes are decoded. 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> |
H A D | decoder.hh | diff 12045:31d9a81ba286 Wed May 24 06:09:00 EDT 2017 Gabe Black <gabeblack@google.com> x86: Rework how VEX prefixes are decoded. 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> |
H A D | types.hh | diff 12045:31d9a81ba286 Wed May 24 06:09:00 EDT 2017 Gabe Black <gabeblack@google.com> x86: Rework how VEX prefixes are decoded. 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> |
/gem5/src/arch/x86/isa/ | ||
H A D | bitfields.isa | diff 12045:31d9a81ba286 Wed May 24 06:09:00 EDT 2017 Gabe Black <gabeblack@google.com> x86: Rework how VEX prefixes are decoded. 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> |
/gem5/src/arch/x86/isa/decoder/ | ||
H A D | decoder.isa | diff 12045:31d9a81ba286 Wed May 24 06:09:00 EDT 2017 Gabe Black <gabeblack@google.com> x86: Rework how VEX prefixes are decoded. 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> |
/gem5/src/systemc/core/ | ||
H A D | sc_process_handle.cc | diff 12994:afce27405f70 Sat Jul 21 01:13:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Fix a "problem" with kill/reset exceptions. Despite what it says in the spec, the proc_ctrl compliance test throws a copy of the reset exception it catches, not the original. Because of that, the code in the kernel which catches the exception gets the base class, not the derived class with overridden virtual methods, etc. This happens to work for the Accellera implementation because they manipulate members of the base class itself which are preserved despite this bug. To make the test work, we imitate their implementation, even though it exposes more implementation details through the header files. Change-Id: I7ed9818c0552869ec790cb7f7bfbe365ade5e49c Reviewed-on: https://gem5-review.googlesource.com/12045 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
/gem5/src/systemc/ext/core/ | ||
H A D | sc_process_handle.hh | diff 12994:afce27405f70 Sat Jul 21 01:13:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Fix a "problem" with kill/reset exceptions. Despite what it says in the spec, the proc_ctrl compliance test throws a copy of the reset exception it catches, not the original. Because of that, the code in the kernel which catches the exception gets the base class, not the derived class with overridden virtual methods, etc. This happens to work for the Accellera implementation because they manipulate members of the base class itself which are preserved despite this bug. To make the test work, we imitate their implementation, even though it exposes more implementation details through the header files. Change-Id: I7ed9818c0552869ec790cb7f7bfbe365ade5e49c Reviewed-on: https://gem5-review.googlesource.com/12045 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
Completed in 42 milliseconds