[fpc-devel] Improved RTTI compromise

[Sven Barth]

On 07.12.2016 16:16, Jonas Maebe wrote:
> 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.

That's however only the code to generate the required RTTI. Invoke()
itself does not yet exist in that branch.

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

Don't worry, you won't need to do that. Since I'm also in support of the
manager architecture as well I can do that, too. Also I'm already aware
of the fact that the RTTI generated in the branch is not sufficient for
multiple parameter locations; that will be something I'll address when I
reintegrate that branch.
Maybe it would be even best to have not a single manager like for
threads or widestrings, but instead one for each calling convention (or
so) so that we could replace certain calling conventions with internal
ones while others continue to use libffi or simply raise ENotSupported
if the calling convention can't be used (e.g. oldfpccall) (which would
also be the default implementation for new targets).

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

The RTTI.Invoke() method does not even use the RTTI. It merely has a
calling convention as parameter and the parameter values so it indeed
would need to basically duplicate the parameter manager of the compiler.
It would be the job of the invoke manager however to translate the
information provided by the RTTI to its own format. We just need to
ensure that we provide sufficient information (e.g. in fact all
parameter (sub)locations so that a general call manager could be used)

Regards,
Sven