Index
> Compiler Internals > Some minor fasm deficiencies.Goto page Previous 1, 2 |
| Author |
|
|
l_inc 09 Jul 2013, 22:17
Tomasz Grysztar
Quote: It is defined that fasm always generates RIP-relative addressing unless the absolute addressing is enforced I don't think, that the documentation defines it as strict as you say. The documentation says the following: 2.1.19 The x86-64 long mode instructions wrote: When no size operator is applied to address, assembler generates the optimal form automatically. One could only guess what "the optimal form" is. Quote: This is important, so that when writing a regular code you can expect that everything is RIP-relative and thus relocatable. I see your point, but in this case RIP-relative makes it non-relocatable, because the address is statically defined and is therefore not a subject to (co-)relocation together with the code. Besides, this argumentation seems to break when you try to apply it to the next case from the paragraph 2: Code: org 100000000h lea edx,[0] ;fails to compile. Not OK. because EIP-relative addressing makes the instruction only partially co-relocatable with the address 0, i.e. within the aligned 2^32 bytes region. I mean it's perfectly OK for me, if you say, that the absolute addressing must always be enforced in 64 bit mode (and otherwise it's RIP- or EIP-relative). Just as a matter of language definition. But you can't defend this design decision with the code position independence argumentation. Quote: What could be improved here, is an error message - perhaps fasm should tell that it cannot generate RIP-relative address and hint that instruction may be compilable by adding the absolute addressing enforcing This seems reasonable to me. Speaking about error messages, what would be your comment on the following one? Code: format PE64 DLL at $4000000 mov rax,[$4001000] ;error: invalid use of symbol. section '.reloc' fixups data readable executable _________________ Faith is a superposition of knowledge and fallacy |
|||
09 Jul 2013, 22:17 |
|
|
l_inc 04 Aug 2013, 16:03
Tomasz Grysztar
Quote: Modifying a value in uninitialized data block with "store" directive will now correctly mark this data as initialized when it is in a different addressing space. This issue is still present: Code: rb 1 space:: virtual rb 1 ;<- somehow this is crucial store byte 'A' at space:0 end virtual _________________ Faith is a superposition of knowledge and fallacy |
|||
|
04 Aug 2013, 16:03 |
|
|
Tomasz Grysztar 04 Aug 2013, 19:06
I try to resolve this issue with 1.71.12 release.
|
|||
|
04 Aug 2013, 19:06 |
|
|
l_inc 04 Aug 2013, 19:24
Tomasz Grysztar
Thank you. It seems to work correctly now. P.S. But I still can't compile: Code: use64 org 100000000h lea edx,[0] with eip-relative addressing.  _________________ Faith is a superposition of knowledge and fallacy |
|||
|
04 Aug 2013, 19:24 |
|
|
l_inc 05 Aug 2013, 10:51
Tomasz Grysztar
I've got one more question. Is the following behaviour expected to be correct? Code: org -1 db 'A' load a from $FFFFFFFFFFFFFFFF On one hand such behaviour allows an important possibility to store labels as qword's and stay sure, that the labels when loaded back can still be used as pointers with the load/store directives. On the other hand I remember you said you'd like a programmer to be unaware of the implemented arithmetic width. Thus my question is whether the wraparound behaviour is expected and whether one can rely on this to stay unchanged in the future. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
05 Aug 2013, 10:51 |
|
|
Tomasz Grysztar 27 Jan 2014, 17:26
l_inc wrote: Tomasz Grysztar Code: a = -0FFFFFFFFFFFFFFFFh org a ; error, as with "dq a" |
|||
|
27 Jan 2014, 17:26 |
|
| Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|