Hello,

I would like to inform you that the interfacertti branch contains the wrong patch !

E.g for i386, it implements:
ti386paramanager.get_para_regoff
but it should be:
tcpuparamanager.get_para_regoff

This is valid for all implemented architectures (i386, X86_64, arm)

Correct patch (hopefully) included !

Should be fixed by now.

mfg Steve

Hello to all,

Coming back from a long vacation, I saw today that there are some major changes (trunk) made to ncgrtti.pas.

As you may perhaps know, I do have some interest in somewhat extended (interface) rtti.
The initial extended rtti is saved in a separate branch. And working for me !
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/interfacertti/

But new ncgrtti.pas and current interfacertti branch are very incompatible right now.

Are there any plans to sync the rtti branch with new changes made towards ncgrtti.pas ?

Thanks.

Hi,
already did the changes but have jet to find the time to integrate them in the branch.
Currently they are only in a local git branch.
What would be the best approach concerning a "svn rebase" ?

mfg Steve

Steve Hildebrandt wrote

already did the changes but have jet to find the time to integrate them in the branch. Currently they are only in a local git branch. What would be the best approach concerning a "svn rebase" ?

Rebasing a publicly published branch is generally not a good idea (even when using pure git), because it invalidates all local changes that other people might have. So either you create a new branch in which these rebased changes go, or instead you merge the changes, make your changes (which may consist of just copying over the results from your rebase and then adding the file) and commit.

Note that when merging using git-svn, you must add the following to your ~/.gitconfig or in .git/config of the clone:

[svn]
pushmergeinfo = true

Additionally, merge with "--no-ff". If you do those two things (and don't rebase afterwards), git-svn will properly update the svn merge information in the remote repository.

Jonas

I did a rebase only for my local branch.
So it is easy to merge the svn branch.
I don't want to use svn-git since I'm neither confident everything is setup right nor will end up the way I want it to.
The local git is more or less only a playground for me. But since I already did the work there it should be easy to do a merge in the RTTI branch.
What I wanted to know is, in which way can I integrate the current svn trunk in the RTTI branch, preventing headache for anyone using it.

Steve

Steve Hildebrandt wrote

What I wanted to know is, in which way can I integrate the current svn trunk in the RTTI branch, preventing headache for anyone using it.

1) check out the rtti svn branch
2) svn merge ^/trunk
-> you'll get conflicts for ncgrtti.pas, postpone conflict resolution
3) copy your rebased ncgrtti.pas over the one with conflicts
4) svn resolved compiler/ncgrtti.pas
5) svn commit

Jonas

Thanks and done.

Steve

Thanks for making the changes to the RTTI branch !

However, this branch does not compile, unless the following files are added !

compiler\owomflib.pas
packages\mysql\src\mysql57dyn.pp
packages\winunits-base\src\shlwapi.pp
packages\fcl-web\src\base\httpprotocol.pp
packages\fcl-web\src\base\cgiprotocol.pp
packages\fcl-web\src\base\fpwebclient.pp
packages\fcl-web\src\base\fpjwt.pp
packages\fcl-web\src\base\fpoauth2.pp
packages\fcl-web\src\base\fpoauth2ini.pp
packages\fcl-web\src\base\fphttpwebclient.pp
packages\fcl-web\src\base\restbase.pp
packages\fcl-web\src\base\restcodegen.pp
With these files, compiling is ok.

Running tests i386 (Win8.1).

Testing the RTTI features reveals a small difference between the old and the new RTTI version.
All other RTTI features still work and also work as expected !

Again, tested i386 on Win8.1

procedure A2(const A: TIntegerArray);
Previous stack size: 4.
New stack size: 0.
Previous ParReg: 255.
New ParReg: 1.
These two were the only differences on i386 with the new RTTI !

I'm a bit confused as to why some files went missing. I will look into this issue.

I changed nothing concerning the code generating the actual information, since they are only derived from information already available during the compiler run.
Seems like FPC now handles this diffrent.
Is this compatible with delphi?
If this is a problem at all, what calling convention was used?

msf Steve

Should be ok now.
Please Report back.

regards Steve

All ok now.
Branch compiles out-of-the box for Windows i386 and crosswin32-64. FPC 2.6.4 used as bootstrap (through fpcup).

Test-programme (Win8.1) reports success on both i386 and x86-64.

Remarkable: the previous reported changes to compensate for changes in StackSize and ParReg for test A2 on i386 still needed, but no changes were needed for x86-64 !

Have still to test on ARM.

Thanks, Alfred.

Am 27.08.2015 um 17:28 schrieb Steve Hildebrandt: >Should be ok now. Please Report back.

Florian changed it in r30870.

Is this compatible with delphi?

Delphi compatibility was probably the reason, yes.

Jonas

I would like to report back about RTTI.

RTTI Branch was tested on RPi2 (ARMV7A, hardfloat), win32/64 (Win8.1), Linux i386 (Arch VM) and Linux64 (Ubuntu VM).

I did encounter some new alignment issues again on ARM (see checkMethod).
But some other alignment issues have vanished (see checkParam).

Also some register values did change:
Stacksize difference between Win64 and Linux64
Other difference most visible in : checkMethod(p, 'TestStdCall', ....

The included TestInterfaceRTTI.lpr runs flawless on all of my (VM-) systems and on RPi2.

Thanks !

No problem.
Can you check again with this diff applied?
If this doesn't work I'm a bit clueless.
Since I have no platform available to test alignment issues on, maybe you can look into it.

Steve

After your patch:

TestInterfaceRTTI.lpr (from today) runs fine without any change on ARM. Removing / adding any alignment in TestInterfaceRTTI causes errors. Strange !

I also have no clue.

On my systems, current RTTI now in full use in combi with the mORMot ORM !

Few questions remains:

1: Compiler flag
Question: Would it be possible to add a flag into this branch, so programmes can automagically detect the presence of Interface RTTI ?

2: Alignment
Using brute force (due to lacking compiler knowledge), I could dig into ARM alignment issues. No problem.
However, at the moment, the issues are known (and correctly implemented in mORMot).
So, I have to know the goal.
This cast works again: PVmtMethodParam(p)^
This cast does not work: PIntfMethodEntry(p)^
Question: What alignment issues should have to be solved ?

I would like to ask for an update of the InterfaceRTTI branch, due to some important fixes in FPC trunk !
Would that be possible ?

Thanks.

Isn't it simply possible to merge the InterfaceRTTI branch with the FPC trunk?
It sounds to be quite fine and working for Win32, Win64 and ARM targets.

I remember that there was some interesting discussion about including a new interface code execution feature, similar to Delphi's RTTI Invoke. But even if this feature is not available, having the RTTI is already very interresting.
It allows to generates some wrapper code, or even use some runtime-generated asm (as we do for Win32, Win64 and Linux in our Open Source mORMot).

What do you think of merging the InterfaceRTTI branch with the FPC trunk?

Thanks for the good work.
I can say that with latest info about Delphi embracing ARC for the upcoming Linux 64 target, we consider using only FPC as main compiler for our server-side projects.

Arnaud

Done by Steve !

Thanks very much !!

2015-11-21 12:06 GMT+01:00 Arnaud Bouchez :

What do you think of merging the InterfaceRTTI branch with the FPC trunk?

Indeed. Very important... Ping core team?

Arnaud Bouchez wrote

we consider using only FPC as main compiler for our server-side projects.

This is good news for me because I am developing a client-server application with mORMot and FPC as well :) But I am still on the very beginning.

Ondrej

I have not had chance to look at the RTTI branch, but RTTI is very critical for any modern language, and the main FPC branc was hopelessly out of date the last time I checked. It was not able to compile any part of our code base as it is heavily RTTI dependent.
Improving the RTTI support in FPC and bringing it at least to the level of the Delphi one is critical for the overall FPC success IMHO, and will allow us to port and offer all of our components in FPC .

With best regards,
Boian Mitov

------------------------------------------------------- Mitov Software
www.mitov.com
-------------------------------------------------------

2015-11-22 12:45 GMT+01:00 Maciej Izak :

No one can help? Sven? I think it is very close to your interests?

To the best of my knowledge:

The patch will not be merged to trunk, not today, not tomorrow, because the mechanism is not generic and highly processor specific.

As long as there is no mechanism that is known to work on all supported CPUs, this will not be merged.

We are making a cross-platform compiler. So it is of paramount importance that new features work on ALL cpus, not just the most-used ones.

Michael.

Michael Van Canneyt wrote on Wed, 25 Nov 2015:

I'll have a look at how to make it generic once the llvm backend works for Darwin/x86_64 (which should be soon).

Jonas

One must admire the subtle announcement in this reply ;-)

Michael.

trunk?

Just one word: time. Nothing more, nothing less.

Regards,
Sven

Can someone refer me to a document regarding the whats planned for FPC RTTI improvements? Is it aiming to support the current Delphi RTTI improvements (attributes, virtual method intercepts, location and tvalue) or something else?

Anthony Walter wrote

Can someone refer me to a document regarding the whats planned for FPC RTTI improvements? Is it aiming to support the current Delphi RTTI improvements (attributes, virtual method intercepts, location and tvalue) or something else?

There is no document.

To my knowledge:

- Attributes are supported in a branch already scheduled to be merged after 3.0.0 is out.

- The location and tvalue are in the branch for which the merge request was just posted.

- I think virtual method intercepts are not implemented or planned. I am not sure whether this needs many extra things in the compiler, it just requires the interface RTTI and a RTL helper class ?

Michael.

2015-11-25 15:00 GMT+01:00 Michael Van Canneyt :

for us, mORMot users and contributors, for now the improvements included in InterfaceRTTI branch are fine to keep engine without workarounds ( http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/interfacertti/?sortby=date&view=log ).

RTTI

> improvements? Is it aiming to support the current Delphi RTTI

improvements

after 3.0.0 is out.

- The location and tvalue are in the branch for which the merge request

was just posted.

- I think virtual method intercepts are not implemented or planned. I am not sure whether this needs many extra things in the compiler, it

just

requires the interface RTTI and a RTL helper class ?

Virtual method interceptors are not implemented, but they are planned just like every other Delphi compatible part of the RTTI. They require a bit of platform dependent support though as they'll need to deal with calling conventions (even if it might only be one as AFAIK we only allow the default calling convention for virtual methods...).

Regards,
Sven

Sounds like the same code as for interface method RTTI can be reused.

Michael.

But that will only provide half of it, because a Virtual Method Interceptor (VMI) also needs to provide the callee while for the interface method RTTI (or later on Invoke()) you only need to provide the necessary means to call the function (which a VMI needs to be able to do as well, which is what I mean "half").

Regards,
Sven

Hmh. Why does it need to provide the callee ?
I thought it just meant inserting a stub in the VMT and make sure all arguments are passed correctly ?

No doubt you know better :)

Michael.

The method stub needs to call the OnBefore and OnAfter handlers before and after calling the virtual method that had been intercepted (and here it needs to know which method had been intercepted as well, because *all* virtual methods are hooked), thus it needs to preserve the original arguments across the calls to OnBefore and OnAfter (this would not be required if passed on the stack, but e.g. on i386 the register calling convention is used which stores stuff in registers). In addition it needs to pass on the parameters to the handlers and return the result. So it indeed needs to provide a full callee.

Regards,
Sven

Michael Van Canneyt wrote

One must admire the subtle announcement in this reply ;-)

I know, right?? :)

Jonas Maebe wrote

I'll have a look at how to make it generic once the llvm backend works for Darwin/x86_64 (which should be soon).

The llvm support for Darwin is what I've been waiting for. :)

Jonas Maebe wrote

I'll have a look at how to make it generic once the llvm backend works for Darwin/x86_64 (which should be soon).

"llvm backend works" does it also means the possibility to import in FreePascal some C++ classes from external libraries ?

"Jy V" wrote

On Wed, Nov 25, 2015 at 5:06 PM, Jonas Maebe

> > I'll have a look at how to make it generic once the llvm backend works

for Darwin/x86_64 (which should be soon).

"llvm backend works" does it also means the possibility to import in

FreePascal some C++ classes from external libraries ?

LLVM has *nothing* to do with the ability to handle C++ classes. For this further work on the cppclass feature will be needed.

Regards,
Sven

2015-11-25 11:06 GMT+01:00 Jonas Maebe :

I'll have a look at how to make it generic once the llvm backend works for Darwin/x86_64 (which should be soon).

FPC -> LLVM -> JavaScript *___*

Maciej Izak wrote on Fri, 27 Nov 2015:

No. LLVM IR platform dependent. So if you want to compile Pascal to "Javascript LLVM IR", you first have to add a "Javascript LLVM IR" platform to FPC. That includes both compiler and RTL support.

Jonas

2015-11-27 11:59 GMT+01:00 Jonas Maebe :

No. LLVM IR platform dependent. So if you want to compile Pascal to "Javascript LLVM IR", you first have to add a "Javascript LLVM IR" platform to FPC. That includes both compiler and RTL support.

I thought it would be simpler.

If you perform a readln, you need to call some kind of OS or platform function to read data from standard input. From Javascript you obviously cannot access the system calls or C library of the underlying operating system (and if you could, it wouldn't help much, since you would want to read from a browser Windows), so you need an RTL.

In general, as I've mentioned several times before on this list, LLVM is not a panacea:
* LLVM IR completely platform dependent, so it does not automagically give us access to all targets supported by Clang/LLVM. In particular the way calling conventions are handled is completely platform dependent, and you cannot generate "generic LLVM IR" that will work on all platforms (at least not in an ABI-compliant way), and of course the size of integer
* LLVM does not care about backward compatibility, so FPC will always only support a subset of available LLVM versions
* LLVM does not support the Borland "register" calling convention, so i386 support will be impossible until someone adds that to LLVM

Jonas

2015-11-27 12:36 GMT+01:00 Jonas Maebe :

In general, as I've mentioned several times before on this list, LLVM is not a panacea:

anyway thanks to your efforts, implementation of Javascript LLVM IR platform should be easier? "X LLVM IR" is somehow related to "Y LLVM IR"?

Maciej Izak wrote

anyway thanks to your efforts, implementation of Javascript LLVM IR platform should be easier? "X LLVM IR" is somehow related to "Y LLVM IR"?

Yes.

Jonas

Jonas Maebe wrote

* LLVM does not support the Borland "register" calling convention, so i386 support will be impossible until someone adds that to LLVM

Unless it would be an LLVM-specific i386 target without the register calling convention ?

Regards,

Adriaan van Os

Adriaan van Os wrote

Unless it would be an LLVM-specific i386 target without the register calling convention ?

That wouldn't fit at all in the FPC project. Compatibility is our game, and I wouldn't want to be the one having to support an "almost compatible target" (even separately from the fact that our RTL would have to be adapted to a lack of the register calling convention on i386).

Jonas