flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > "qword" size operator for address

Author
Thread Post new topic Reply to topic
CandyMan



Joined: 04 Sep 2009
Posts: 316
Location: film "CandyMan" directed through Bernard Rose OR Candy Shop
CandyMan
See below:

use64
add al,[qword -128] ;code: 02042580FFFFFF

flat assembler version 1.69.09 (3402751 kilobytes memory)
TEST.ASM [2]:
add al,[qword -128]
error: invalid size of address value.
Post 27 Oct 2009, 15:03
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17620
Location: In your JS exploiting you and your system
revolution
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]    
Post 27 Oct 2009, 16:52
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7781
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 27 Oct 2009, 21:18
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17620
Location: In your JS exploiting you and your system
revolution
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.
Post 28 Oct 2009, 01:31
View user's profile Send private message Visit poster's website Reply with quote
asmfan



Joined: 11 Aug 2006
Posts: 392
Location: Russian
asmfan
Intel also says
Quote:

RIP-relative addressing is enabled by 64-bit mode, not by a 64-bit address-size. The use of the address-size prefix does not disable RIP-relative addressing. The effect of the address-size prefix is to truncate and zero-extend the computed effective address to 32 bits.

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?
Post 28 Oct 2009, 12:09
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7781
Location: Kraków, Poland
Tomasz Grysztar
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
Post 28 Oct 2009, 16:24
View user's profile Send private message Visit poster's website Reply with quote
asmfan



Joined: 11 Aug 2006
Posts: 392
Location: Russian
asmfan
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?
Post 28 Oct 2009, 17:11
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7781
Location: Kraków, Poland
Tomasz Grysztar
asmfan wrote:
still no consistency when disp32 is RIP and when abs
Unless you use the size operator, the RIP-relative is used. Always and consistently. With size operator you can force the absolute addressing.
This is a documented behavior.
Post 28 Oct 2009, 17:40
View user's profile Send private message Visit poster's website Reply with quote
asmfan



Joined: 11 Aug 2006
Posts: 392
Location: Russian
asmfan
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?
Post 31 Oct 2009, 19:22
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7781
Location: Kraków, Poland
Tomasz Grysztar
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    
has to generate the 67h prefix (so that zero-extension is used). And so it does.
Post 31 Oct 2009, 21:05
View user's profile Send private message Visit poster's website Reply with quote
asmfan



Joined: 11 Aug 2006
Posts: 392
Location: Russian
asmfan
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?
Post 01 Nov 2009, 10:06
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7781
Location: Kraków, Poland
Tomasz Grysztar
Right, that perhaps shall be corrected, too.
Post 01 Nov 2009, 10:21
View user's profile Send private message Visit poster's website Reply with quote
asmfan



Joined: 11 Aug 2006
Posts: 392
Location: Russian
asmfan
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 Wink)
Post 01 Nov 2009, 10:42
View user's profile Send private message Reply with quote
asmfan



Joined: 11 Aug 2006
Posts: 392
Location: Russian
asmfan
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)
Post 02 Nov 2009, 09:26
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.