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

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

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

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