| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
New approach to disambiguating /disp32 arguments: based on opcodes rather
than metadata.
I interpret /disp32 as PC-relative in a short list of instructions. Otherwise
it's absolute if it gets a label.
There should be no reason to pass labels into /disp8 or /disp16.
|
| |
|
|
| |
Go back to commit 7448.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's an ambiguity in how x86 interprets disp32 fields:
- For jumps and calls they're displacements from the starting address of
the next instruction. So far so good.
- However, when the ModR/M requires them they can also be absolute addresses.
Ideally I'd take the presence of the ModR/M byte into account in interpreting
them.
However, it's easier to assume relative addressing only for labels in the
code segment.
This commit raises an error if we ever refer to labels in the code segment
in instructions with a ModR/M byte. (I'm assuming that no instruction with
a ModR/M byte will ever use a displacement without the ModR/M byte requiring
it.)
|
| |
|
|
|
| |
subx.md distinguishes between operands and arguments. Let's use that terminology
more consistently in the sources.
|
| | |
|
| |
|
|
| |
Give the bootstrap C++ program a less salient name.
|
| |
|