Index
> Compiler Internals > "qword" size operator for address |
| Author |
|
|
revolution 27 Oct 2009, 16:52
In 64bit mode you have to use RIP relative addressing. Trying to access a fixed qword address can be done by loading it into a register first.
Code: use64 mov rcx,-128 add al,[rcx] |
|||
27 Oct 2009, 16:52 |
|
|
Tomasz Grysztar 27 Oct 2009, 21:18
No, he is right, that code should work and generate exactly the opcode he gave. fasm is able to assemble "add al,[dword -128]" in 64-bit mode, into the same opcode with 67h prefix, as it makes the address to be zero-extended instead of sign extended. Thus you should get:
Code: add al,[dword -128] ; code: 6702042580FFFFFF, address used: 00000000FFFFFF80 add al,[qword -128] ; code: 02042580FFFFFF, address used: FFFFFFFFFFFFFF80 But the second variant doesn't work with current version, even though I thought it should. Perhaps I overlooked something. |
|||
|
27 Oct 2009, 21:18 |
|
|
revolution 28 Oct 2009, 01:31
Oh yeah, the AMD manual is clearer than Intel for this. The SIB allows for absolute memory addresses (+-2GB only) in 64bit mode. But without SIB it becomes RIP+-2GB.
|
|||
|
28 Oct 2009, 01:31 |
|
|
asmfan 28 Oct 2009, 12:09
Intel also says
Quote:
then anyway it's hard to get FFFFFF80h in disp32 if RIP is used. Maybe some consistency in treating [real] labels and/vs. immediates to clarify RIP mechanism? Or i'm totally confuzed looking to 1.68 fasmw output in this qword/dword case?) _________________ Any offers? |
|||
|
28 Oct 2009, 12:09 |
|
|
Tomasz Grysztar 28 Oct 2009, 16:24
Assembly of "add al,[qword -128]" is fixed in in 1.69.10.
asmfan wrote: then anyway it's hard to get FFFFFF80h in disp32 if RIP is used. This should do it: Code: add al,[eip+0FFFFFF80h] Check out this thread, too: http://board.flatassembler.net/topic.php?t=5942 |
|||
|
28 Oct 2009, 16:24 |
|
|
asmfan 28 Oct 2009, 17:11
1.69.10 outputs different for
Code: add al,[qword -128] add al,[-128] still no consistency when disp32 is RIP and when abs( Actually even spoken about qword i ment the absense of it too (FASM still operates in 64bit ints?) cuz qword can be unspoken as implied in 64bit mode addressing (exact. 32bit SignExt.). Will [rip+disp32]/[eip+disp32] only be considered as clear RIP addressing only? And any other is direct abs addr modes? |
|||
|
28 Oct 2009, 17:11 |
|
|
Tomasz Grysztar 28 Oct 2009, 17:40
asmfan wrote: still no consistency when disp32 is RIP and when abs This is a documented behavior. |
|||
|
28 Oct 2009, 17:40 |
|
|
asmfan 31 Oct 2009, 19:22
Continuing the prefixes
Code: use64 mov [dword 0], cx mov cx, [dword 0] treated as abs addressing w/ 16bit operands (66h) but not 32-bit (no 67h) but full 64-bit. The problem i guess only for direct and not for indirect addressing modes. May I assume that directly specifying the size in brackets also set address sizes for direct memory address in 64bits? |
|||
|
31 Oct 2009, 19:22 |
|
|
Tomasz Grysztar 31 Oct 2009, 21:05
fasm, as usual, optimizes the instruction size, and this is why it does not generate 67h in this case. For the absolute addresses in range 0-7FFFFFFFh it doesn't matter whether they are zero-extended or sign-extented to 64 bits, therefore fasm chooses the shorter instruction variant, with sign extension. However this one:
Code: use64 mov [dword 80000000h],cx |
|||
|
31 Oct 2009, 21:05 |
|
|
asmfan 01 Nov 2009, 10:06
Also can it be explained that abs. addressing above 2G can be encoded w/ [dword imm32] (67h) and not [qword imm32]? Sign-extension in one case and zero-ext. to all 64bits in other? But zero-base in abs mode anyway then any sign-extension leads to wrong address in [2G+; 4G] direct range w/o 67h prefix?
|
|||
|
01 Nov 2009, 10:06 |
|
|
Tomasz Grysztar 01 Nov 2009, 10:21
Right, that perhaps shall be corrected, too.
|
|||
|
01 Nov 2009, 10:21 |
|
|
asmfan 01 Nov 2009, 10:42
hmm, I meant it's right that ranges over 2G in abs. addressing aren't allowed (by fasm) for displacement and the only way to go [2G; 4G) ranges is to use 67h. This just what i meant and just clearing it for myself not pointing some fasm errors (btw dunno what corrections are you talking about
 ) |
|||
|
01 Nov 2009, 10:42 |
|
|
asmfan 02 Nov 2009, 09:26
Oh i see the point
Code: use64 mov cx,[dword 80000000h] ; assembles well while the rest abs indirect addressing modes mov cx,[ecx+80000000h] ; fail this is it.?(c)M.J. Code: mov e(rax), moffs64 can it give other than out of range when [moffs64] is used? Confusing that explicit [qword ] must be used to encode it (which is easy to forget) |
|||
|
02 Nov 2009, 09:26 |
|
< Last Thread | Next Thread > |
Forum Rules:
|