As of revision 5831, I've enabled -Cg for x86_64-linux building. This means all code is built with PIC so you can build libraries without recompiling the fpc rtl etc. However, this might have some downsides: first, pic'ed code is slightly slower, second, pic support still might contain bugs so please share your findings and opinions.

Op Sat, 6 Jan 2007, schreef Florian Klaempfl:

How difficult do you think it is to use RIP relative addresses to access global variables? That way there should be no speed difference, allowing us to remove the -Cg switch on x64-64.

Daniël

How should this look like?

global variables? That way there should be no speed difference, allowing us to remove the -Cg switch on x64-64.

Op Sat, 6 Jan 2007, schreef Florian Klaempfl:

Assume we have:

var global:byte;
procedure z;
begin
  global:=1;
end;

Referencing to z without PIC would be an absolute memory access, preventing us to place z in memory where we want without breaking the code. Normally with -Cg we do something like:

call FPC_GETEIPINEBX
add rbx,dword global_offset_table
mov [rbx + offset_of_global_in_datasegment].byte,1

... to get access to the variable. With x64_64 you can do:

mov [global wrt rip].byte,1

The assembler must translate this to:

mov [rip-data_segment_distance+offset_of_global_in_datasegment].byte,1

... where offset_of_global_in_datasegment is a constant and data_segment_distance symbol that is resolved by the linker.

RIP relative addresses are more efficient than absolute addresses, because an absolute address is always stored as 64 bit, while the RIP offset is encoded as a 32 bit signed value (8 bit in x86 tradition possible as well, but usually the datasegment is further away than 128 bytes), the processor can decode them faster.

Daniël

Well, to be correct it allows to map physical pages with code at different virtual address in different processes. Without PIC they could be only relocated for one address.

Well, amd64 does this basically but it stores only the address to the actual data rip relative so you need an additional redirection. This point is stored in the got section. I wonder indeed if one could abuse the got to actually store data :)