Some minor fasm deficiencies.

Index > Compiler Internals > Some minor fasm deficiencies.

Goto page Previous 1, 2

Author

Thread

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 7848
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.

09 Jul 2013, 11:08

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

09 Jul 2013, 22:17

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

04 Aug 2013, 16:03

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 7848
Location: Kraków, Poland

Tomasz Grysztar

I try to resolve this issue with 1.71.12 release.

04 Aug 2013, 19:06

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

04 Aug 2013, 19:24

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

05 Aug 2013, 10:51

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 7848
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.

27 Jan 2014, 17:26

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