[fpc-devel] Improved RTTI compromise
jonas.maebe at elis.ugent.be
Wed Dec 7 16:16:49 CET 2016
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.
More information about the fpc-devel