yaxpeax-x86/src/long_mode, branch 0.2.2 yaxpeax x86 decoder fix ShowContextual rendering error with stale data and operands, publish 0.2.2 2021-05-17T02:00:03+00:00 iximeow me@iximeow.net 2021-05-17T02:00:03+00:00 beff8d0f33bc4152422c175ff720fdba0dc021da 






remove dead OperandSpec variants
2021-05-07T07:12:37+00:00

iximeow
me@iximeow.net

2021-05-07T07:12:37+00:00

bf4dc7ee2fd352a01deda314da82af588dd50952












update yaxpeax-arch to 0.0.5, fix interface breakages
2021-05-07T07:12:19+00:00

iximeow
me@iximeow.net

2021-05-07T07:12:19+00:00

2ad06203b892a1b6bc3ea9769066d1a959aef690












remove some forgotten println comments
2021-03-22T00:42:41+00:00

iximeow
me@iximeow.net

2021-03-22T00:42:41+00:00

66734f55a994bf4b8654e355a250e6e2abb4d75d












include memory sizes on inc/dec in C format
2021-03-22T00:40:39+00:00

iximeow
me@iximeow.net

2021-03-22T00:40:39+00:00

3ee3f55f9a5239664ff9fb0d4b73926c4d76ac26












make Opcode, Operand, and DecodeError non_exhaustive
2021-03-21T21:30:17+00:00

iximeow
me@iximeow.net

2021-03-21T21:30:17+00:00

fcd9fc30d2fa41b2267a6539e5806735bae8931d

in the future these can and will change (new operands, new instructions) and i would prefer they not be major breaking changes. applications can ignore them and probably do undesired variants anyway.

if you want to write a 1120-variant match, are you me? why would you do this





in the future these can and will change (new operands, new instructions) and i would prefer they not be major breaking changes. applications can ignore them and probably do undesired variants anyway.

if you want to write a 1120-variant match, are you me? why would you do this







in real programs, having read_operands inlined hurts performance!
2021-03-21T21:09:41+00:00

iximeow
me@iximeow.net

2021-03-21T21:09:41+00:00

0591d78e5b1c1c232fd6c6e4c159fd428f19ade9

the in-repo benchmark got better with this inlined but it's probably
better to leave it up to the compiler when finally stitching stuff
together. i suspect that having read_operands inlined resulted in just
too many live values, and the compiler was inspired to play hijinks that
pipelined poorly. disas-bench shows a ~15% improvement from this change.





the in-repo benchmark got better with this inlined but it's probably
better to leave it up to the compiler when finally stitching stuff
together. i suspect that having read_operands inlined resulted in just
too many live values, and the compiler was inspired to play hijinks that
pipelined poorly. disas-bench shows a ~15% improvement from this change.







fuzzing shows resetting operands is not beneficial
2021-03-21T18:41:35+00:00

iximeow
me@iximeow.net

2021-03-21T18:41:35+00:00

72d1231dd24f5682b0ac752abe8233d750b397e4












fix potential successful decodes with Opcode::Invalid
2021-03-21T18:41:18+00:00

iximeow
me@iximeow.net

2021-03-21T18:40:56+00:00

12251de92baadedbecca2048740959b0f965ffc5

vmov* are.. somehow messed up too





vmov* are.. somehow messed up too







add tsxldtrk
2021-03-21T10:19:51+00:00

iximeow
me@iximeow.net

2021-03-21T10:19:51+00:00

22baa577c5ba34bc4e89b7019f2666ff7cee4b07

does intel know no bounds





does intel know no bounds