Index
> Compiler Internals > bug with absolute addressing in use64? |
| Author |
|
|
vid 16 Mar 2007, 10:46
Code: mov rax, [dword 0x80000000] mov rax, [dword 0xFFFFFFFF80000000] these two instruction assemble to same instruction... bug? |
|||
16 Mar 2007, 10:46 |
|
|
Tomasz Grysztar 16 Mar 2007, 19:38
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. |
|||
|
16 Mar 2007, 19:38 |
|
|
vid 17 Mar 2007, 08:22
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. |
|||
|
17 Mar 2007, 08:22 |
|
|
Tomasz Grysztar 17 Mar 2007, 12:18
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. |
|||
|
17 Mar 2007, 12:18 |
|
|
vid 17 Mar 2007, 12:56
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? |
|||
|
17 Mar 2007, 12:56 |
|
|
Tomasz Grysztar 17 Mar 2007, 13:06
vid wrote: does that mean instruction "mov eax, [dword 0xFFFFFFFF80000000]" actually accesses address 0x0000000080000000 ? 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. |
|||
|
17 Mar 2007, 13:06 |
|
|
Tomasz Grysztar 17 Mar 2007, 13:13
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.
|
|||
|
17 Mar 2007, 13:13 |
|
|
MazeGen 21 Mar 2007, 16:31
Tomasz Grysztar wrote: ... Thanks for clearing up the mess, Tomasz. Nevertheless, given this instruction: Code: use64 mov rax,[8000000000000000h] The manual says: Quote:
It doesn't seem so: Quote:
It works only with explicit qword operator: Code: use64 mov rax,[qword 8000000000000000h] so it is probably a bug. |
|||
|
21 Mar 2007, 16:31 |
|
|
Tomasz Grysztar 21 Mar 2007, 16:33
No, it's an error in manual (bad formulation, in fact).
 Thanks for pointing this out. |
|||
|
21 Mar 2007, 16:33 |
|
|
MazeGen 21 Mar 2007, 16:38
Well, you mean you force an user to use a qword operator here? If so, why fasm couldn't assemble it without the operator?
|
|||
|
21 Mar 2007, 16:38 |
|
|
Tomasz Grysztar 21 Mar 2007, 16:42
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.
|
|||
|
21 Mar 2007, 16:42 |
|
|
Tomasz Grysztar 21 Mar 2007, 16:46
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...
|
|||
|
21 Mar 2007, 16:46 |
|
|
MazeGen 21 Mar 2007, 16:56
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 ), 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" 
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 |
|||
|
21 Mar 2007, 16:56 |
|
|
Tomasz Grysztar 21 Mar 2007, 19:51
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.
Surely that's my weak point (and thus fasm's, too). |
|||
|
21 Mar 2007, 19:51 |
|
|
vid 21 Mar 2007, 20:32
you are lazy because you want to keep useless .COM version, aren't you?
 |
|||
|
21 Mar 2007, 20:32 |
|
< Last Thread | Next Thread > |
Forum Rules:
|