| Age | Commit message (Collapse) | Author |
|---|
|
|
|
it turns out that yaxpeax-arch's notion of colorization has been broken from the start for systems that do markup without inline sequences (e.g. windows/cmd.exe before vt100 support)
|
|
`name()` returning a `[u8; 2]` is nice when there is a specializing and
unrolling write implementation, whereas `&str` might not consistently
unroll into a simple 2-byte copy (rather than loop). it'll look a little
more reasonable soon, hopefully..
|
|
|
|
|
|
write_2 will never actually be used, but im adapting it into contextualize in a... better way
|
|
the reasoning for *why* `visit_operand` is better here lives as doc
comments on `visit_operand` itself: it avoids going from scattered
operand details to `enum Operand` only to deconstruct the enum again.
instead, branch arms can get codegen'd directly against `struct
Instruction` layout.
|
|
this reduces a `slice::contains` to a single bit test, and regroups
prefix printing to deduplicate checks of the `rep` prefix
seemingly this reduces instruction counts by about 1%, cycles by 0.3% or
so.
|
|
the match on opcode should have been dce, match on operands would only matter if there was a bug
|
|
|
|
|
|
testing against six opcodes to see if we should print rep or repnz is a
bit absurd. they are relatively rare instructions, so this is a long
sequence of never-taken tests. we can avoid the whole thing in the
common case by testing if there is any kind of rep prefix at all.
|
|
for mem size labels: add one new "BUG" entry at the start of the array
so `mem_size` does not need to be adjusted before being used to look
up a string from the `MEM_SIZE_STRINGS` array. it's hard to measure
the direct benefit of this, but it shrinks codegen size by a bit and
simplfies a bit of assembly....
for segment reporting changes: stos/scas/lods do not actually need
special segment override logic. instead, set their use of `es` when
decoded, if appropriate. this is potentially ambiguous; in non-64bit
modes the sequence `26aa` would decode as `stos` with explicit `es`
prefix. this is now identical to simply decoding `aa`, which now also
reports that there is an explicit `es` prefix even though there is no
prefix on tne instruction.
on the other hand, the prefix-reported segment now more accurately
describes the memory selector through which memory accesses will
happen. seems ok?
|
|
registers `al`, `cl`, `dl`, and `bl` could have two different
representations - with `rex.w` and without. these two forms of `RegSpec`
would not compare equal, nor has the same, so for code relying on
`RegSpec` to faithfully represent a 1-1 mapping to x86 registers, these
synonyms would introduce bugs in register analysis.
for example, in `yaxpeax-core`, this would result in instructions
writing to `rex.w al` not being visible as definitions for a future
read of `!rex.w al`.
fix this in `x86_64` code, add new test cases about the confusion,
adjust register names to make this situation more clearly a bug, and
introduce two new fuzz targets that would have helped spot this error.
|
|
|
|
|
|
|
|
these coincidentally have the general-purpose banks (rB excepted) matching their size in bytes
|
|
|
|
Closes https://github.com/iximeow/yaxpeax-x86/issues/16
|
|
|
|
|
|
This makes generated docs refer to a type and show said type in the list of all structs rather than rustdoc showing gray text in return types.
quote doc references
|
|
|
|
|
|
while x86 branches of immediates are all relative to PC, other
architectures may have absolute branches to immediate addresses, leaving
this syntax ambiguous and potentially confusing. yaxpeax prefers to
write relative offsets `$+...` as a rule, so uphold that here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the evex route would allow "valid" instructions that have the opcode
`invalid`. this is.. not correct.
|
|
also remove redundant assignments of operand_count and some OperandSpec,
bulk-assign all registers and operands on entry to `read_instr`. this
all, taken together, shaves off about 7 cycles per decode.
|
|
|
|
|
|
|
|
|
|
|
|
instructions
|
|
|
|
|
|
|
|
does intel know no bounds
|
|
|
|
|
|
|
