flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > bug with absolute addressing in use64?

Author
Thread Post new topic Reply to topic
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Code:
mov rax, [dword 0x80000000]
mov rax, [dword 0xFFFFFFFF80000000]    

these two instruction assemble to same instruction... bug?
Post 16 Mar 2007, 10:46
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
What actually means "dword 0xFFFFFFFF80000000"? According to the fasm's manual, it should be "absolute 32-bit addressing", but that address is out of 32 bits (32-bit addresses are not sign-extended in 64-bit mode).
Post 16 Mar 2007, 11:09
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
MazeGen wrote:
32-bit addresses are not sign-extended in 64-bit mode.

That depends on the 67h prefix. With it, they are zero-extended, otherwise sign-extended. For example of two instructions:
Code:
xor rax, [dword 0x7FFFFFFF]
xor rax, [dword 0x80000000]    

the first one won't generate 67h prefix, as it's not needed, but the second one will.

However "MOV rAX,[addr]" is a special case, here 67h prefix affects the address value in the instruction - that's why 67h is generated by all instructions above.

As for the treating "0xFFFFFFFF80000000" the same as "-0x80000000h", this is a side-effect of some features of the fasm's core that I have no remedy for right now. Those values are internally the same for fasm.
Post 16 Mar 2007, 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
Quote:
However "MOV rAX,[addr]" is a special case, here 67h prefix affects the address value in the instruction - that's why 67h is generated by all instructions above.
So how are instruction then executed? With sign-extending? Is it really possible to encode "mov rax, [dword 0x80000000]"?
Post 17 Mar 2007, 08:22
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: 7796
Location: Kraków, Poland
Tomasz Grysztar
vid wrote:
Is it really possible to encode "mov rax, [dword 0x80000000]"?

Yes, the 67h prefix causes the 32-bit address to be zero-extended.
Post 17 Mar 2007, 12: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
does that mean instruction "mov eax, [dword 0xFFFFFFFF80000000]" actually accesses address 0x0000000080000000 ?

this may be somewhat confusing. Maybe you could disallow using "[dword val]", when val is greater than 0xFFFFFFFF?
Post 17 Mar 2007, 12:56
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: 7796
Location: Kraków, Poland
Tomasz Grysztar
vid wrote:
does that mean instruction "mov eax, [dword 0xFFFFFFFF80000000]" actually accesses address 0x0000000080000000 ?

this may be somewhat confusing. Maybe you could disallow using "[dword val]", when val is greater than 0xFFFFFFFF?

Of course it's disallowed to use "dword" value greater than 0xFFFFFFFF. The problem of fasm's core is that (as I already pointed above) 0xFFFFFFFF80000000 is the same internally as -0x80000000, which is a valid value for dword.

The possible solution would be to disallow unsigned 64-bit numbers larger than 0x7FFFFFFFFFFFFFFF. However I guess some people that use calculations on such numbers would be a bit disappointed by such restriction.
Post 17 Mar 2007, 13:06
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Well, there is a "proper" solution - to add additional sign bit to the symbol values, but that would require a bit large changes to the whole core... That's why I never tried it.
Post 17 Mar 2007, 13:13
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
Tomasz Grysztar wrote:
...

Thanks for clearing up the mess, Tomasz.

Nevertheless, given this instruction:
Code:
use64

mov rax,[8000000000000000h]
    

The manual says:
Quote:

There is also one exception, where the 64-bit absolute addressing is possible, it's the mov instruction with one of the operand being accumulator register, and second being the memory operand. To force the assembler to use the 64-bit absolute addressing there, use the qword size operator for address inside the square brackets. When no size operator is applied to address, assembler generates the optimal form automatically.

It doesn't seem so:
Quote:

flat assembler version 1.67.21 (555693 kilobytes memory)
mov_rax_moffs.asm [4]:
mov rax,[8000000000000000h]
error: value out of range.

It works only with explicit qword operator:
Code:
use64

mov rax,[qword 8000000000000000h]
    

so it is probably a bug.
Post 21 Mar 2007, 16:31
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
No, it's an error in manual (bad formulation, in fact). Wink Thanks for pointing this out.
Post 21 Mar 2007, 16:33
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
Well, you mean you force an user to use a qword operator here? If so, why fasm couldn't assemble it without the operator?
Post 21 Mar 2007, 16:38
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
For long mode fasm generates absolute addressing only when directly asked - I got kind of feeling that absolute addresses are generally "bad" in x64 programming.
Post 21 Mar 2007, 16:42
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
As I think about it, I recall that perhaps some of the early versions of x64-supporting fasm were allowing this, and that may be reason why the manual says so...
Post 21 Mar 2007, 16:46
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
Tomasz Grysztar wrote:
For long mode fasm generates absolute addressing only when directly asked - I got kind of feeling that absolute addresses are generally "bad" in x64 programming.

You're right, but this way you confuse users (for instance, me Wink), because that instruction exist, is valid and encodable. The error message should be explanatory, something like "value out of range; use qword operator to force absolute addressing" Smile
You know, nobody like go to the manual and find the correct syntax. Additionally, these x64 stuff is quite messy and few users know it well so the assembler should help the users some way instead of confusing them Wink
Post 21 Mar 2007, 16:56
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Oh, you know, I'm just too lazy to add a new error messages as long as I'm able to find already existing one that even barely fits. Wink Surely that's my weak point (and thus fasm's, too).
Post 21 Mar 2007, 19:51
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
you are lazy because you want to keep useless .COM version, aren't you? Wink Razz
Post 21 Mar 2007, 20:32
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number 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.