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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
