yaxpeax-x86/src/long_mode, branch x86-generic yaxpeax x86 decoder remove a few duplicate impls, add stubs for geneirc translations 2023-01-02T16:50:23+00:00 iximeow me@iximeow.net 2022-08-28T00:08:29+00:00 d2b4f3d1a454c7bbcc487ddfb2839b01dc1c9c9e generate_opcode.py has quickly grown into generating much more than just opcode definitions, and now handles a few duplicate impls across the different decode modes as well. some of the added impl generation conflicts with still-existing hand-written impls from yore, so they needed a bit of removing. next will be the addition of a generic module for "probably what you want" disassembly of x86, avoiding the 64-/32-/16-bitness of the architecture family with an attempt to decode "probably what you wanted" from a byte sequence. it needs a little more work still, but TODO stubs added here support that new module. 
generate_opcode.py has quickly grown into generating much more than just
opcode definitions, and now handles a few duplicate impls across the
different decode modes as well. some of the added impl generation
conflicts with still-existing hand-written impls from yore, so they
needed a bit of removing.

next will be the addition of a generic module for "probably what you
want" disassembly of x86, avoiding the 64-/32-/16-bitness of the
architecture family with an attempt to decode "probably what you wanted"
from a byte sequence. it needs a little more work still, but TODO stubs
added here support that new module.
codegen `Colorized` impl and normalize `name()` implementation 2023-01-02T16:50:23+00:00 iximeow me@iximeow.net 2022-07-24T01:23:25+00:00 d5eafcbc374357a66794297a60c3a7a2b035bff3 unfortunately because of the layout of instruction information this *adds* lines rather than removes them.. 
unfortunately because of the layout of instruction information this
*adds* lines rather than removes them..
yax builds again with opcodes generated by type 2023-01-02T16:50:22+00:00 iximeow me@iximeow.net 2022-07-22T09:15:40+00:00 e6e7fabfc907eaf016520d9c2a2e128b0d28f019 






fix incorrect rex selection and field description offsets
2022-12-03T23:11:09+00:00

iximeow
me@iximeow.net

2022-05-01T20:53:51+00:00

635bf0336fe2f654945a23a6b59591866cdb1d2e












66 prefixes are common, 0f opcodes are common
2022-12-03T23:11:09+00:00

iximeow
me@iximeow.net

2022-04-23T02:49:43+00:00

f11d0c17363fbd73e14e3db92cc0bd7d8d80dcf2












support a fast path through the decoder for [rex-prefixed]opcode insts
2022-12-03T23:11:09+00:00

iximeow
me@iximeow.net

2022-04-21T09:35:38+00:00

e1b3633e9595abdd4714a18bae9d5b0aeaed8a80

the overwhelming majority of x86 instructions are either a single-byte
opcode or a single-byte opcode with a rex prefix. supporting these
specially means that we don't have to length-check on every byte or
go through the full decode loop while reading the most likely
instructions. this is a significant improvement on typical x86 streams,
but comes at a moderate penalty for crafted x86 instructions.

the penalty is still not very bad, as the fast path is exited in favor
of the full decode loop as soon as we see a non-rex prefix byte; this
adds maybe a dozen instructions to the slow path.





the overwhelming majority of x86 instructions are either a single-byte
opcode or a single-byte opcode with a rex prefix. supporting these
specially means that we don't have to length-check on every byte or
go through the full decode loop while reading the most likely
instructions. this is a significant improvement on typical x86 streams,
but comes at a moderate penalty for crafted x86 instructions.

the penalty is still not very bad, as the fast path is exited in favor
of the full decode loop as soon as we see a non-rex prefix byte; this
adds maybe a dozen instructions to the slow path.







just a bit more code motion that seemed to help things sometimes
2022-12-03T23:11:09+00:00

iximeow
me@iximeow.net

2022-04-21T09:35:09+00:00

c15999d4a5afa1e2e3e6d6c227135dfd5cf28780












reorder prefix checks, extract vex/evex prefix handling
2022-12-03T23:11:09+00:00

iximeow
me@iximeow.net

2022-04-21T09:31:40+00:00

76418a5a934c99ef918070c3c740ce3eceb6c5bb

sharing vex/evex invalid prefix checks improves codegen a bit, but
ordering prefix checks by likeliest prefix first reduces time falling
through prefix handling arms. both together are a notable improvement in
throughput on typical x86 code.

bundled in here is some code motion to where `mem_size = 0` and
`operand_count = 2` are executed; this is because, at least on zen2 and
cascade lake parts, bunching all stores to the instruction together
caused small stalls getting into the decoder. spreading out stores seems
to mix these assignments with parts of code that was not using memory
anyway, and pipelines better.





sharing vex/evex invalid prefix checks improves codegen a bit, but
ordering prefix checks by likeliest prefix first reduces time falling
through prefix handling arms. both together are a notable improvement in
throughput on typical x86 code.

bundled in here is some code motion to where `mem_size = 0` and
`operand_count = 2` are executed; this is because, at least on zen2 and
cascade lake parts, bunching all stores to the instruction together
caused small stalls getting into the decoder. spreading out stores seems
to mix these assignments with parts of code that was not using memory
anyway, and pipelines better.







move opcode lookup tables into const arrays
2022-12-03T23:11:09+00:00

iximeow
me@iximeow.net

2022-04-21T09:28:34+00:00

f5cfe59ce7b7a62ec57325d4d742608b9ae20929

cleanliness, but also slightly better codegen somehow?





cleanliness, but also slightly better codegen somehow?







replace size lookup logic with a LUT
2022-12-03T23:11:09+00:00

iximeow
me@iximeow.net

2022-04-21T09:27:38+00:00

20d3219cf05b9ba30dc5a336d735af07f054e4cb

the match compiled into some indirect branch awfulness!! no thank you





the match compiled into some indirect branch awfulness!! no thank you