[fpc-devel] Improved RTTI compromise

[Jonas Maebe]

On 07/12/16 14:38, Sven Barth wrote:
> But aside from that you could indeed already start to implement
> Invoke(), maybe based on the mORMot code.

That code is also in fpc/branches/interfacertti. But as mentioned in 
earlier threads about this, I think it should be generalised in a way 
that does not require basically duplicating the compiler's parameter 
manager for every current and potential future architecture also in the RTL.

A previously proposed way centred around some kind of manager interface 
(like we have for the heap and widestrings), which would be general 
enough to support interfacing with libffi (and which hence could be used 
as a generic fallback for every architecture).

The problem is that I am the one supposed to define this interface (for 
the RTL manager) and the data structures to support it (i.e., to be 
generated as RTTI by the compiler), and I really don't care at all for 
this functionality or the related work. I only intervened in this topic 
because I don't want to be on the receiving end the next time I add 
support for a new architecture or OS (or even for existing targets, as 
the current register/offset approach is insufficient; e.g., it does not 
support multiple parameter locations for a single parameter).

In fact, the manager approach and/or libffi may not even help. On the 
one hand, libffi probably does not even need extra information beyond 
standard RTTI, as it just uses standard ABI-defined entities (8/16/.. 
bit integer, 32/64/.. bit floating point, vectors, struct with list of 
fields, pointer, ...) and from that calculates the necessary parameter 
location information. You would need code in the RTL to convert the 
standard RTTI to this libffi format though, or do it in the compiler and 
encode that too in the RTTI.

On the other hand, that would not be enough information for the current 
approach, since that one relies on the compiler encoding the actual 
parameter locations in the RTTI and then adding architecture-specific 
code to the RTL (or currently: program) to interpret these locations. So 
then you still need to add, maintain and extend the current approach 
anyway if you want to be able to offer a non-generic solution that does 
not duplicate the entire parameter manager of the compiler.


Jonas