Closed bchurchill closed 9 years ago
A potential fix for this is in the issue-197 branch, but I'm not going to merge it into develop until it works in stoke.
Shouldn't we use something other than the index for the OPC comment? I'm worried that this is going to cause problems when we change the table again in some way, and suddenly the indices mean different things depending on the version of x64asm. Couldn't we just use the Opcode string representation? It would have the advantage of being stable across different versions of x64asm as well as being readable by humans.
Yeah, I was thinking about that. This behavior already is in existence in the parser but it's easy to change.
On 07/29/2015 07:09 AM, Stefan Heule wrote:
Shouldn't we use something other than the index for the OPC comment? I'm worried that this is going to cause problems when we change the table again in some way, and suddenly the indices mean different things depending on the version of x64asm. Couldn't we just use the Opcode string representation? It would have the advantage of being stable across different versions of x64asm as well as being readable by humans.
— Reply to this email directly or view it on GitHub https://github.com/StanfordPL/x64asm/issues/197#issuecomment-125963164.
Yeah, I know, this issue just brought it back into my mind, and I think we should fix it. We can do it here, or create a new ticket for it.
Here is fine. It's hardly any work for me to fix this.
On 07/29/2015 02:02 PM, Stefan Heule wrote:
Yeah, I know, this issue just brought it back into my mind, and I think we should fix it. We can do it here, or create a new ticket for it.
— Reply to this email directly or view it on GitHub https://github.com/StanfordPL/x64asm/issues/197#issuecomment-126094911.
Closed in 95ff3cdc7a97cc6
Right now, if you want to generate a jump with a label, x64asm will always generate it with a 32-bit displacement. It should be possible though to use a different opcode to get an 8-bit displacement.
In the spreadsheet, there are correctly rows for three versions of a given jump instruction, with 8-, 16- and 32-bit offsets. (16 bits isn't valid in 64-bit mode). The
Codegen
tool then generates opcodes for each of these, and also an opcode for jumping to a label. That 'jump to label' "opcode" only corresponds to 32-bit offset opcode on the hardware.In this ticket,
Codegen
will now generate two such fake "opcodes" for jumping to a label, one for 8-bit and the other for 32-bit offsets. By default, the parser will still choose the 32-bit version, but this can be overridden using a # OPC=nnnn in the comment, where nnnn is the index of the opcode in the x64asm table (or alternatively with a SIZE=n comment).Now, when you assemble a
Code
, there's the possibility x64asm will fail if you've requested to use a jump with an 8-bit displacement but the jump target is more than 127 bytes away (in either direction). That means you need to check the return value ofAssembler::finish()
.