flat assembler
Message board for the users of flat assembler.

Index > Main > moffset64

Author
Thread Post new topic Reply to topic
lazer1



Joined: 24 Jan 2006
Posts: 185
lazer1
How do I use moffset64?

the docs say:
Quote:

MOV RAX,moffset64 A1 move 64-bit data at a specified memory offset to the rax register




I tried:

Code:
         org 1234567812
use64
    mov rax,qword [x]

x:
    


which has hex:

Code:
00000000 :48 8B 05 00 00 00 00
    


and the opcode is 48 not A1, Sad

I also tried:

Code:
    org 1234567812
use64
    mov rax, x

x:
    


with hex

Code:
00000000 :48 B8 1C 78 56 34 EE FF - FF FF
    

opcode 48 also not a1, Confused

these are just code fragments, so they clearly wont run
I'm looking for the fragment that compiles to the opcode A1,

its a compile time question not a run time question, Surprised

likewise how are moffset8, moffset16, moffset32 invoked? Razz
Post 23 Apr 2006, 13:34
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
It's:
Code:
mov rax,[qword x]    

The "qword" applies here to the size of address, not operand. As:
Code:
mov eax,dword [qword x]    

copies 32-bit value adressed by 64-bit offset.

See 2.1.19.
Post 23 Apr 2006, 13:51
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
I know this is a question of using RIP-relative addressing, but shouldn't 64-bit offset be used by default in use64 code? Such syntax seems to be quite confusing...
Post 23 Apr 2006, 16:09
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
For most of the instructions you cannot use 64-bit offset. And for "mov rax,[...]" still the RIP-relative encoding is shorter (and position-independent!), thus fasm favors it for the default one.

This syntax forces the offset to be encoded as a full size. For example:
Code:
mov eax,[dword 1+ecx]    

as opposed to
Code:
mov eax,[1+ecx]    

which would optimize encoding and use 8-bit displacement.

This is the analogous mechanism to the one used for instructions like:
Code:
add eax,1 ; optimized
add eax,dword 1 ; forced long immediate    


In general, when you don't provide a size operator for a number/address, assembler optimizes the encoding of instruction, otherwise it uses the specified full size for it.
Post 23 Apr 2006, 16:17
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
I get it, thanks for explanation! Smile
Post 23 Apr 2006, 16:29
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
still not thinking about allowing to force shorter form?

Wink
Post 23 Apr 2006, 18:04
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
Still thinking that error checking should be strict for sizes (and look here).
I'm not so easily changing the design that took me so much thinking to be invented. Wink
Post 23 Apr 2006, 19:38
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i still don't get why you consider that as design change.

Code:
cmp eax, A ;let compiler decide
cmp eax, dword A ;force encoding: cmp rm32, imm32
cmp eax, byte A ;force encoding: cmp rm32, imm8    


Would that make error checking less strict for sizes? In every case when you want to write "cmp eax, byte A", short form would be generated anyway with "cmp eax, A", using this you can only make sure that long form won't be created, and so prevent error.

For me "cmp eax, dword A" has exactly same place in design as "cmp eax, byte A"
Post 23 Apr 2006, 21:01
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
But "cmp eax,byte A" is the same size conflict as "cmp eax,al".

The real use of the case, when you need the short form to be forced, is actualy rare. For the most of the time, when you use instruction mnemonics, you focus on their function, not encoding (for such reason Intel architecture has the same mnemonics for instructions that have different opcodes, but perform the same function). Thus fasm tries to make sure that every encoded instruction would follow up to expectation on how it functions, leaving the encoding customizability for the second place. Reducing the error checking in case of not matching sizes is not an option. But, fortunately for me, only forcing the long encoding was actually needed, as forcing short encoding is the same as just checking whether value is out of range - what in those (as already said: rare) cases when you needed it could be achieved with simple IF. Thus I made this trick that putting the size operator with the numerical expression enforces the full size for that immediate/displacement. This doesn't conflict with the functionality rules, as for someone focusing on the function of instruction, it still does the same, as one would expect - there's nothing confusing in comparing double word with double word, but comparing double word with byte certainly is (from the functionality point of view).

PS. Such change would be actually reversing the direction of fasm's evolving, as this solution was used earlier, and was abandoned in favor of the current one, as I realized the assembly language itself is much more for focusing on the functionality than on the instruction encoding.
Post 24 Apr 2006, 06:18
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
well then, if it's your opinion. now i at last comprehend you.

for me, comparing dword to signed-extended byte isn't breaking functionality rules nor confusing. It's perfectly clear and understandable.

btw, would allowing this cause any problems, except that it doesn't exactly match your design? I mean real problems, like something would need to be changed etc.
Post 24 Apr 2006, 08:09
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
No, it wouldn't cause any problems - as I already mentioned, this would be simply reverting the changes back to how it was done earlier. You can check this out: initially when I was implementing this change in design, I forgot to update the "imul" instruction to the new behavior; if you download the 1.56 or some earlier version from archives, you can check that it still assembled things like "imul eax,byte 0".
Post 24 Apr 2006, 10:50
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: 17492
Location: In your JS exploiting you and your system
revolution
The current method seems inconsistent. We have to know we have a qword value and give the override manually.

What if I use:
Code:
use64
mov [someaddress],eax    
How can I know the size of someaddress? Do I have to always put:
Code:
use64
mov [qword someaddress],eax    
just to be sure I get it to assemble?

Maybe this instead?:
Code:
use64
if someaddress<1 shl 32
  mov [dword someaddress],eax
else
  mov [qword someaddress],eax
endif    
And what happens if someaddress is in fact an equ for "ebp-4"? Then the "if" above fails.

With use16 default address size is 16bit, no need for forced override for words.
Also FASM automatically generates 067h override if the address is too big
Code:
use16
mov[1 shl 16],eax       ;generates address size override automatically    

With use32 default address size is 32bit, no need for forced override for dwords.

But, with use64 now things are different:
With use64 default address size is 64bit, but we need forced overrides for qwords!
Code:
org 1 shl 32
use64
mov[1 shl 32],eax       ;Error: value out of range. Why not generate "mov[rip-6],eax"?
mov[dword 1 shl 32],eax ;no error, but value of out of range!
mov[qword 1 shl 32],eax    
Post 24 Apr 2006, 13:17
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
With use64 default address is RIP-relative. Because it's optimal in many terms, eg. doesn't need relocations. Thus the absolute addressing has to be forced by programmer if he really needs it (but I would call it almost deprecated in the long mode).
Post 24 Apr 2006, 14:23
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
There is still one more problem with consistency here - it's the "jmp byte". My excuse was that the size operator applies here to the size of displacement, not the address - but perhaps it would be better to use the "short" type instead. I just thought about it and I'm almost sure it should be corrected this way.
Post 24 Apr 2006, 14:42
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: 17492
Location: In your JS exploiting you and your system
revolution
Quote:
With use64 default address is RIP-relative.
Code:
org 1 shl 32 
use64 
mov[1 shl 32],eax       ;Error: value out of range. Why not generate "mov[rip-6],eax"?    
Post 24 Apr 2006, 15:04
View user's profile Send private message Visit poster's website Reply with quote
lazer1



Joined: 24 Jan 2006
Posts: 185
lazer1
Tomasz Grysztar wrote:
With use64 default address is RIP-relative. Because it's optimal in many terms, eg. doesn't need relocations. Thus the absolute addressing has to be forced by programmer if he really needs it (but I would call it almost deprecated in the long mode).


first, thanks for the explanation at the start,

I think your design is right, I explain from my POV
where in theory alternatives have problems:

you might have several different regions of address space eg:

Code:
0 to 4G    system code, eg just 32K or something, but with 
              the full 4G so any amount will fit,

4G to 8G  user code, again maybe just the first 16K for an actual program,

8G to 12G  large stack area, grows downwards from 12G, maybe just 16K
                actually used,
12G to 30G data area for eg a film, beginning with a header,
    


now when the user code wants some system data it needs eg:

Code:
character_width   equ  20000h
use64
          mov eax,[dword character_width]
    


here character_width might be eg at address 20000h,
so the dword prefix will mean it is an external reference
to system data,

to read the header you might do:
Code:
film_size_address equ (3 shl 32)   ; address 12G 
use64
       mov  rax,qword [qword film_size_address]
    


not that I am going to do this! Very Happy

but its a hypothetical scenario,

the advantage is that this code is still relocatable!

just the system and data areas arent, but the
user code could be loaded to a different area of memory
and still run,

a real example is that B8000h is an absolute location, so
you might do:

Code:
           org  123456789h
    ....
use64
    mov  byte [dword 0B8000h], '?'
    mov  byte [dword 0b8001h], 1110001b
    


the B8000h region for 80x25 text can be regarded as nonrelocatable,

so you need nonrelocatable addressing to refer to it,

if you remapped then you could change its address but you may
wish to remap it to a different absolute address beyond the 32 bit
addresses,
Post 24 Apr 2006, 19:54
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
revolution: it was because of the same bug that this: http://board.flatassembler.net/topic.php?t=5158
and thus it is fixed now.
Post 25 Apr 2006, 20:12
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: 17492
Location: In your JS exploiting you and your system
revolution
Thanks for the fixes.
Post 26 Apr 2006, 00:30
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Tomasz Grysztar wrote:
There is still one more problem with consistency here - it's the "jmp byte". My excuse was that the size operator applies here to the size of displacement, not the address - but perhaps it would be better to use the "short" type instead. I just thought about it and I'm almost sure it should be corrected this way.


Not sure if this is what you meant, but when I'm writing 16-bit .COM files, I wish FASM didn't try to make short-jumps-that-don't-fit into near jumps. I'd rather do a 16-bit workaround than have FASM assume a 386+ fix. To avoid FASM working behind my back (without my knowledge), I define short equ byte. In other words, that works for me, but go ahead and change whatever it is you're talking about. Confused
Post 26 Apr 2006, 22:21
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
So now you can just remove "short equ byte", as "short" is now supported natively and "byte" causes an error.
Post 27 Apr 2006, 08:27
View user's profile Send private message Visit poster's website 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 YouTube, Twitter.

Website powered by rwasa.