yaxpeax-x86/src, branch 0.2.0 yaxpeax x86 decoder and clean up some warnings 2021-03-23T06:40:20+00:00 iximeow me@iximeow.net 2021-03-23T06:15:26+00:00 c8b2e95a59e830b68ddaee671f56127690918198 






port long-mode decoder updates to protected-mode
2021-03-23T06:08:54+00:00

iximeow
me@iximeow.net

2021-03-23T06:08:54+00:00

0fff2a6aa0832b1cabf381e0c970f0fd47223224












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







xed says setssbsy and saveprevssp are more permissive
2021-03-21T09:58:48+00:00

iximeow
me@iximeow.net

2021-03-21T09:58:48+00:00

d7b07d3eb6e6dc614fbc13cb66b951cb93daec44