[fpc-devel] RTTI interface & variant late binding issue (mORMot)
Steve.Kassel at web.de
Mon Mar 23 13:57:52 CET 2015
Am 22.03.2015 um 10:38 schrieb Michael Van Canneyt:
> On Sun, 22 Mar 2015, Alfred wrote:
>> Hello again to all,
>> I am enjoying variant late binding AND interface RTTI for a while now !
>> Thanks again !
>> As far as I know, the patch for RTTI has not yet been included in trunk.
>> But correct me if I am wrong.
>> I would like to ask to include the RTTI patch for i386 in trunk.
>> With i386 interface RTTI, FPC is on level with Kylix for the RTTI part.
>> To ease introduction, I would like to suggest to include a new
>> HASINTERFACERTTI flag, which will let the FPC user know, the new RTTI
>> is available for use.
>> At this moment, it will only be i386.
> I can't remember when I last used i386 code. Must have been more than
> 10 years ago.
>> But I hope also ARM will be included in the trunk.
>> On my Raspberry Pi2, the new RTTI works flawless.
> The core developers are divided on the approach to take. Hence it is
> not yet included.
> The code is highly non-portable, which means that each platform must
> be maintained separately.
> This means additional pressure on people who maintain these other
> The idea is to use a manager approach (as for instance for threads,
> locale, widestrings)
> using a libffi wrapper as fallback for platforms for which no native
> manager is available.
> (see https://sourceware.org/libffi/)
> However this means the RTTI info must be written in a format that can
> be fed directly to libffi.
> (or using a conversion routine). In each case, additional work is needed.
> My - and Florian Klaempfl's, if I understood correctly - idea is to
> include what exists, and then modify the code as needed so it can work
> with libffi. Others fear that this will mean the ffi wrapper will not
> get written anytime soon.
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.
While leaving the possibility of specific corrections if need be by
Maybe it is just me missing the bigger picture, so please correct me if
I am wrong.
More information about the fpc-devel