flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Some minor fasm deficiencies.

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
The 1.71.11 release addresses some of the problems you found. I still did not analyze everything you posted, though - I may prepare another related release later.
Post 09 Jul 2013, 11:08
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
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
Post 09 Jul 2013, 22:17
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
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
Post 04 Aug 2013, 16:03
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
I try to resolve this issue with 1.71.12 release.
Post 04 Aug 2013, 19:06
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
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. Smile

_________________
Faith is a superposition of knowledge and fallacy
Post 04 Aug 2013, 19:24
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
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
Post 05 Aug 2013, 10:51
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
l_inc wrote:
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.
The addressing used by ORG/LOAD and other such directives is 64-bit, and thus it operates on the truncated range. So when the value is converted into an address for ORG or LOAD directive, it follows the same truncation process as when you use it as a data for DQ directive. This is a simple example that demonstrates this:
Code:
a = -0FFFFFFFFFFFFFFFFh
org a  ; error, as with "dq a"    
Therefore you don't need to worry about this changing in the future, it works as it should.
Post 27 Jan 2014, 17:26
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:  
Goto page Previous  1, 2

< 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.