| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Previously, immediate-shifted-register and register-shifted-register
data-processing instructions were decoded using separate decoding paths,
which caused extra complexity. These two forms differ only in the
interpretation of their shifting constructs, which is already handled
through the `RegShift` type.
This change also fixes instructions like `cmp r0, r1, lsl r2` from being
decoded with an extra operand.
|
|
|
|
This also incidentally fixes an issue where MOV/MVN instructions with a
shifted operand could be decoded as if they had 3 operands.
|
|
There's a pattern of load/store instructions that look something like
* `ldr<variant> <target registers>,
[<base register>, +/- <offset register>]`
* `str<variant> <target registers>,
[<base register>, +/- <offset register>]`
These instructions share a common encoding format, which includes the
presence of 4 reserved bits starting at bit 8 in the instruction word.
These bits should always be zero, according to
`DDI0406C_d_armv7ar_arm.pdf`. However, while this crate did attempt to
validate these bits sometimes, the validation was inverted. Instead of
checking that the bits were zero, the validation would raise an error if
all of the bits were zero! Additionally, some instructions were missing
the check and some instructions that did not use the aforementioned
encoding scheme incorrectly had the check applied to them.
This commit fixes all of the issues I've found along these lines so far.
|
|
|
|
|
|
|
|
|
|
initially was "implement MCR/MRC decoding", but expanded to include the
whole coprocessor space for completeness, and then SVC is right there
too.
Neon instructions in this space are still rejected, as neon support is
not really there yet.
Co-authored-by: iximeow <me@iximeow.net>
|
|
they share exactly the same encoding, except the high bits for condition
the bool indicates if it's A2 encondings which is unconditional
|
|
|
|
but exhaustiveness checking is very valuable here, so allow it to be
disabled. caveats apply. read the docs in Cargo.toml.
|
|
this makes a decode+format benchmark drop from 75s to 14s...
(decode is 5s)
|
|
both from_u8 and the build function here compiled to truly trivial code:
four instructions (mov rdi, rax; cmp 0xlim, rax; jae panic; ret) in the
hot path, and constrained register choice on the caller side. inlining
these makes for a *smaller* armv7 decoder, on the order of 5kb down from
5.5kb. in the process it also gets about 45% faster (400mb/s to 560mb/s)
inlining decode_into, then, really just helps the standalone decoder
benchmark case. this moves decode throughput from 560mb/s to 724mb/s.
|
|
fix bitvec syntax changes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in fact the decoder should _never_ panic. included here are tests that
cover the entire 32-bit instruction space and ensure that decoding and
display do not panic. these tests run uncomfortably slowly (1168s to
decode the 4b "instruction" sequences on my desktop), but verify that
panics are no longer an issue.
|
|
only in a64 decoding really; there wasn't an "Incomplete" error at the time, but now there is.
|
|
|
|
|
|
|
|
fix interface changes around YaxColors as well
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mostly confusion of pre/post-increment, operand widths, immediate
widths, things of that nature
|
|
16-bit instructions only, for now
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Operands was an enum covering all forms of operands and data for each
operand for all instructions. this is hard to iterate, and hard to work
with when a single operand is the one of interest, so it's now replaced
by an array of `Operand` enum instances like other architectures.
in the course of this change, several forms of decoding are broken,
while adding support for some earlier-unsupported multiplies and
instructions like msr and clz
also clearly note which document the comments mentioning page
numbers/figures is referencing
|
