[fpc-devel] RTTI interface & variant late binding issue (mORMot)

[Steve Hildebrandt]

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 
> platforms.
>
> 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.
>
> Michael.
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 
overriding get_para_regoff.

Maybe it is just me missing the bigger picture, so please correct me if 
I am wrong.

mfg Steve