Index
> Main > moffset64 |
| Author |
|
|
Tomasz Grysztar 23 Apr 2006, 13:51
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. |
|||
23 Apr 2006, 13:51 |
|
|
MazeGen 23 Apr 2006, 16:09
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...
|
|||
|
23 Apr 2006, 16:09 |
|
|
Tomasz Grysztar 23 Apr 2006, 16:17
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. |
|||
|
23 Apr 2006, 16:17 |
|
|
MazeGen 23 Apr 2006, 16:29
I get it, thanks for explanation!
 |
|||
|
23 Apr 2006, 16:29 |
|
|
vid 23 Apr 2006, 18:04
still not thinking about allowing to force shorter form?
 |
|||
|
23 Apr 2006, 18:04 |
|
|
Tomasz Grysztar 23 Apr 2006, 19:38
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. |
|||
|
23 Apr 2006, 19:38 |
|
|
vid 23 Apr 2006, 21:01
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" |
|||
|
23 Apr 2006, 21:01 |
|
|
Tomasz Grysztar 24 Apr 2006, 06:18
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. |
|||
|
24 Apr 2006, 06:18 |
|
|
vid 24 Apr 2006, 08:09
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. |
|||
|
24 Apr 2006, 08:09 |
|
|
Tomasz Grysztar 24 Apr 2006, 10:50
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".
|
|||
|
24 Apr 2006, 10:50 |
|
|
revolution 24 Apr 2006, 13:17
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 Code: use64 mov [qword someaddress],eax Maybe this instead?: Code: use64 if someaddress<1 shl 32 mov [dword someaddress],eax else mov [qword someaddress],eax endif 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 |
|||
|
24 Apr 2006, 13:17 |
|
|
Tomasz Grysztar 24 Apr 2006, 14:23
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).
|
|||
|
24 Apr 2006, 14:23 |
|
|
Tomasz Grysztar 24 Apr 2006, 14:42
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.
|
|||
|
24 Apr 2006, 14:42 |
|
|
revolution 24 Apr 2006, 15:04
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"? |
|||
|
24 Apr 2006, 15:04 |
|
|
lazer1 24 Apr 2006, 19:54
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! 
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, |
|||
|
24 Apr 2006, 19:54 |
|
|
Tomasz Grysztar 25 Apr 2006, 20:12
revolution: it was because of the same bug that this: http://board.flatassembler.net/topic.php?t=5158
and thus it is fixed now. |
|||
|
25 Apr 2006, 20:12 |
|
|
revolution 26 Apr 2006, 00:30
Thanks for the fixes.
|
|||
|
26 Apr 2006, 00:30 |
|
|
rugxulo 26 Apr 2006, 22:21
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.  |
|||
|
26 Apr 2006, 22:21 |
|
|
Tomasz Grysztar 27 Apr 2006, 08:27
So now you can just remove "short equ byte", as "short" is now supported natively and "byte" causes an error.
|
|||
|
27 Apr 2006, 08:27 |
|
< Last Thread | Next Thread > |
Forum Rules:
|