[fpc-devel] RTTI interface & variant late binding issue (mORMot)

[Steve Hildebrandt]

Am 23.03.2015 um 14:47 schrieb Jonas Maebe:
> Steve Hildebrandt wrote on Mon, 23 Mar 2015:
>> As I see it there is no generall problem with my approach. While the 
>> location(paramgr), the interface(get_para_regoff) and the stored 
>> data(reg: Byte; off: LongInt) are worth some discussion,
>> I think whatever kind of manager like approach will be taken, will 
>> turn out to be not realy different from what I already did.
>>
>> procedure get_para_regoff(proccalloption: tproccalloption; paraloc: 
>> pcgparalocation; out reg: Byte; out off: LongInt);
>>
>> Currently the default implementation does nothing but zero the reg 
>> and off.
>> This would be the place for a potential libffi implementation or any 
>> "generic" solution chosen.
>
> The encoded information cannot be specific to a particular kind of 
> consumer. The encoding format should be sufficiently generic to be 
> able to represent the data required for all platforms, and to provide 
> all the information required by any implementation that will use this 
> information to call routines. The purpose of "manager" units is plug & 
> play: you just add one to the uses clause of your main program, and it 
> works. It cannot require compiling the entire FPC source tree and all 
> used units with a particular command line option.
>
I agree that we need a better format as said above this is worth 
discussing, but unless someone knows all the edge cases we are unable to 
design the data format.
The only thing that comes to my mind is either have different RTTI data 
per platform and generic access, or store all information that is 
neccessary for all supported platforms.
Adding the manager to the main program, does only one thing it moves the 
information generation from compile to run time(not so good), while you 
gain no advantage?
An arm abi manager will be of little use in a win64 program, so there 
are only 2 implementations of importance fallback and win64.
Also there is no aditional cmd option we realy need, since we know what 
platform we target while generating the RTTI.
Or are you reffering to compilerswitches related to how much RTTI data 
is generated?
>> While leaving the possibility of specific corrections if need be by 
>> overriding get_para_regoff.
>>
>> Maybe it is just me missing the bigger picture, so please correct me 
>> if I am wrong.
>
> One example: on some PowerPC64 ABIs, if the last bytes of a record do 
> not fill an entire (64 bit) register (e.g. because 5 bytes are left at 
> the end), they must be passed in most significant bits of that 
> register. In the compiler this is encoded as a "shift value" for that 
> parameter. So you need to be able to encode these shift values in the 
> RTTI.
>
In order to support this you would simply need to open up the interface 
to suit your needs, e.g. add an additional parameter that defaults to 
some value if it is of no use.
If another field shift is needed, we can either encode it somhow, store 
it, or generate it at runtime.

> Custom-encoding everything in a platform-specific way into these reg 
> and offset fields (which then wouldn't have any relation to actual 
> registers or offset values anymore in many cases) would lead to 
> requiring platform-specific decoders in the RTL, which I very much 
> would like to avoid.
>
> I'm also not certain whether over time 255 registers will be enough if 
> you also consider vector registers and all kinds of sub registers that 
> are possible there (single precision scalar, double precision scalar, 
> quad precision scaler (?), 32 bit vector (?), 64 bit vector, 128 bit 
> vector, 256 bit vector -- all times the number of vector parameter 
> registers).
>
>
> Jonas
if we know we may have more than 255 registers nothings stops us from 
using a QWord or whatever we need.
This kind of RTTI will need to be interpreted no matter what, all we can 
do is make this a simple process.
Since supporting things like TValue.invoke, will need an assembler call 
frame that is written once per platform(if you are lucky you may be able 
to reuse parts).

As I see it:
   we have platform specific data
   we need a method for writing this data into the generated RTTI 
(encoded or raw)
   we need a gracefull way of handling not generated data
   this should happen at compile time

either :
TABIData = record
   {$IF defined(i386) or defined(x64)}
   reg : Byte;
   off : Integer;
   {$ELSE} {$IF defined(ppc64)}
   reg : Byte;
   shift : Byte;
   {$IFEND}
   {$IFEND}
   ....
end;

or:
TABIData = record
case platform of
   i386, arm, x64: (
     reg : Byte;
     off : Integer;
   );
   ppc64: (
     reg : Byte;
     shift : Byte;
   );
end;

mfg Steve