Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2005-01

Re: About FPC calling register like Delphi

17 messages · 7 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Carlo Kok
to Michael Van Canneyt: Not 100%, there is 1 routine which is assembler, it's the routine that sets up the stack…
Michael Van Canneyt wrote 29 lines
On Thu, 25 Jan 2007, Alexandre Leclerc wrote: > 2007/1/25, Felipe Monteiro de Carvalho : >> On 1/25/07, Alexandre Leclerc wrote: >>> Yes, I understand that, but I *need* a scripting engine which is based >>> on Pascal. And ROPS is the only one I found that answered my >>> requirements. Also, it's integrated and it's "free", and very fast. >>> >>> If there was another way, I would use it. But since, I must rely on a >>> stable FPC internal to make it work. >> Does this script support other calling conventions? >> >> You could try using stdcall instead of register. It´s much simpler, >> and as stable as it can get. >> >> I remember writing a simple script engine myself, and then I choose to >> support mostly stdcall. > ROPS (RemObjects Pascal Script remobjects.com) is 100% pascal code Not 100%, there is 1 routine which is assembler, it's the routine that sets up the stack when making a call to an imported function. > that you simply use in your own code. The engine compiles in your > application. It then work with the application stack, etc. to execute > native pascal functions and script functions. Quite a nice script > engine. I use it since ages, even when it was not owned by remobjects.

You are right about that. There is a routine that does that, but all it does is copy the prepared data onto the stack (And copy back the result). Now, there are a few problems with PS related to FPC:

* FPC has changed default calling convention once (or twice?)
* The way "register" works on FPC is slightly different from delphi, in delphi special types like interfaces, strings and variant results are passed as var parameters, it seems the easiest fix would be for me to change PascalScript to process results differently for FreePascal.

How does FPC pass a string/variant/interface result actually? Returned in AEX?

Once I know this, I should be able to add an FPCFIX define for this. (So it can be easily undone when FPC supports the same "Register" mode as Delphi does)

Carlo Kok RemObjects Software

Reply by email

Jonas Maebe
to Carlo Kok
Carlo Kok wrote
* FPC has changed default calling convention once (or twice?)

Once afaaik.

Show quoted text 8 lines
* The way "register" works on FPC is slightly different from delphi, in delphi special types like interfaces, strings and variant results are passed as var parameters, it seems the easiest fix would be for me to change PascalScript to process results differently for FreePascal. How does FPC pass a string/variant/interface result actually? Returned in AEX?

Strings: yes. Interfaces results are handled in a Delphi-compatible way since 12/04/2006 (i.e. that's also done that way by 2.0.4). Variant results have always been passed as var parameters afaik (at least 2.0.4 does it).

Once I know this, I should be able to add an FPCFIX define for this. (So it can be easily undone when FPC supports the same "Register" mode as Delphi does)

The main incompatibility is currently still that stack parameters are pushed in reverse order compared to what Delphi does for register calling convention. But that will probably be changed before FPC 2.2 comes out.

Jonas

Reply by email

Alexandre Leclerc

Hi all,

I saw some time ago in a roadmap for the next version (1.2?) - that I can't find anymore - a point about being compatible with Dephi calling register... And I was wondering if anything has changed in FPC regarding this?

(Because I use ROPS and there are issues because it is different from FPC and Delphi and I was waiting that it is /final/ in FPC so that ROPS would work ok, or at least fix the thing /finally/ so that it then works for ever with FPC.)

Best regards.

Alexandre Leclerc

Reply by email

Daniël Mantione
to Alexandre Leclerc

Op Tue, 23 Jan 2007, schreef Alexandre Leclerc:

Show quoted text 11 lines
Hi all, I saw some time ago in a roadmap for the next version (1.2?) - that I can't find anymore - a point about being compatible with Dephi calling register... And I was wondering if anything has changed in FPC regarding this? (Because I use ROPS and there are issues because it is different from FPC and Delphi and I was waiting that it is /final/ in FPC so that ROPS would work ok, or at least fix the thing /finally/ so that it then works for ever with FPC.)

FPC's calling convention is compatible with Delphi, since 1.9.4. There are minor differences in the entry/exit code though, but they do not affect most code.

Daniël

Reply by email

Florian Klaempfl
to Daniël Mantione
Show quoted text 18 lines
Op Tue, 23 Jan 2007, schreef Alexandre Leclerc: > Hi all, > > I saw some time ago in a roadmap for the next version (1.2?) - that I > can't find anymore - a point about being compatible with Dephi calling > register... And I was wondering if anything has changed in FPC > regarding this? > > (Because I use ROPS and there are issues because it is different from > FPC and Delphi and I was waiting that it is /final/ in FPC so that > ROPS would work ok, or at least fix the thing /finally/ so that it > then works for ever with FPC.) FPC's calling convention is compatible with Delphi, since 1.9.4. There are minor differences in the entry/exit code though, but they do not affect most code.

No, afaik stack paramters are pushed in the wrong order.

Reply by email

Alexandre Leclerc
to Florian Klaempfl

2007/1/23, Florian Klaempfl :

Show quoted text 21 lines
Daniël Mantione schrieb: > > Op Tue, 23 Jan 2007, schreef Alexandre Leclerc: > >> Hi all, >> >> I saw some time ago in a roadmap for the next version (1.2?) - that I >> can't find anymore - a point about being compatible with Dephi calling >> register... And I was wondering if anything has changed in FPC >> regarding this? >> >> (Because I use ROPS and there are issues because it is different from >> FPC and Delphi and I was waiting that it is /final/ in FPC so that >> ROPS would work ok, or at least fix the thing /finally/ so that it >> then works for ever with FPC.) > > FPC's calling convention is compatible with Delphi, since 1.9.4. There are > minor differences in the entry/exit code though, but they do not affect most > code. No, afaik stack paramters are pushed in the wrong order.

Yes, this is exactly this problem that causes many issues in ROPS. Sorry, I have not been precise enought, this is about the order stack parameters are pushed.

Alexandre Leclerc

Reply by email

Alexandre Leclerc
to Alexandre Leclerc

I did try a latest version and I think there was no changes on that. (?)

Are there plans to set the param-stack the same order as Delphi or will the actual code always stay like that?

(I ask, because from different FPC release, ROPS always react differently. So I know some things are changing in FPC; but it does not give me the required stability to get a final patch to any problems.)

Best regards.

2007/1/23, Alexandre Leclerc :

Show quoted text 30 lines
2007/1/23, Florian Klaempfl : > Daniël Mantione schrieb: > > > > Op Tue, 23 Jan 2007, schreef Alexandre Leclerc: > > > >> Hi all, > >> > >> I saw some time ago in a roadmap for the next version (1.2?) - that I > >> can't find anymore - a point about being compatible with Dephi calling > >> register... And I was wondering if anything has changed in FPC > >> regarding this? > >> > >> (Because I use ROPS and there are issues because it is different from > >> FPC and Delphi and I was waiting that it is /final/ in FPC so that > >> ROPS would work ok, or at least fix the thing /finally/ so that it > >> then works for ever with FPC.) > > > > FPC's calling convention is compatible with Delphi, since 1.9.4. There are > > minor differences in the entry/exit code though, but they do not affect most > > code. > > No, afaik stack paramters are pushed in the wrong order. Yes, this is exactly this problem that causes many issues in ROPS. Sorry, I have not been precise enought, this is about the order stack parameters are pushed. -- Alexandre Leclerc
Alexandre Leclerc

Reply by email

Jonas Maebe
to Alexandre Leclerc
Alexandre Leclerc wrote
Are there plans to set the param-stack the same order as Delphi or will the actual code always stay like that?

There are plans to change it to be Delphi compatible.

(I ask, because from different FPC release, ROPS always react differently. So I know some things are changing in FPC; but it does not give me the required stability to get a final patch to any problems.)

The problem is that you are extremely dependent on binary abi stability regarding how the compiler handles things internally. I don't think we will ever guarantee that this will become stable. The whole point of having a higher level language compiler is to free yourself from such things (and "yourself" includes the compiler writers themselves).

I understand that this is not true for the way ROPS has been implemented, but that is a (major) downside of implementing things at such a low level. No approach is without its downsides...

Jonas

Reply by email

Alexandre Leclerc
to Jonas Maebe

2007/1/25, Jonas Maebe :

Show quoted text 23 lines
On 25 jan 2007, at 14:44, Alexandre Leclerc wrote: > Are there plans to set the param-stack the same order as Delphi or > will the actual code always stay like that? There are plans to change it to be Delphi compatible. > (I ask, because from different FPC release, ROPS always react > differently. So I know some things are changing in FPC; but it does > not give me the required stability to get a final patch to any > problems.) The problem is that you are extremely dependent on binary abi stability regarding how the compiler handles things internally. I don't think we will ever guarantee that this will become stable. The whole point of having a higher level language compiler is to free yourself from such things (and "yourself" includes the compiler writers themselves). I understand that this is not true for the way ROPS has been implemented, but that is a (major) downside of implementing things at such a low level. No approach is without its downsides...

Yes, I understand that, but I *need* a scripting engine which is based on Pascal. And ROPS is the only one I found that answered my requirements. Also, it's integrated and it's "free", and very fast.

If there was another way, I would use it. But since, I must rely on a stable FPC internal to make it work.

Is the stack order & management something complex to correct (I'm not pushing, just informing myself, since I don't know anything in compilers.)

Regards.

Alexandre Leclerc

Reply by email

Jonas Maebe
to Alexandre Leclerc
Alexandre Leclerc wrote 10 lines
> I understand that this is not true for the way ROPS has been > implemented, but that is a (major) downside of implementing things at > such a low level. No approach is without its downsides... Yes, I understand that, but I *need* a scripting engine which is based on Pascal. And ROPS is the only one I found that answered my requirements. Also, it's integrated and it's "free", and very fast. If there was another way, I would use it. But since, I must rely on a stable FPC internal to make it work.

I only option I see in that case is sticking to a particular version of FPC and of ROPS which are known to work together.

Is the stack order & management something complex to correct

I don't know.

Jonas

Reply by email

Felipe Monteiro de Carvalho
to Alexandre Leclerc: 2007/1/25, Jonas Maebe : Yes, I understand that, but I *need* a scripting engine which is…
Alexandre Leclerc wrote 6 lines
Yes, I understand that, but I *need* a scripting engine which is based on Pascal. And ROPS is the only one I found that answered my requirements. Also, it's integrated and it's "free", and very fast. If there was another way, I would use it. But since, I must rely on a stable FPC internal to make it work.

Does this script support other calling conventions?

You could try using stdcall instead of register. It´s much simpler, and as stable as it can get.

I remember writing a simple script engine myself, and then I choose to support mostly stdcall.

Felipe Monteiro de Carvalho

Reply by email

Alexandre Leclerc
to Felipe Monteiro de Carvalho

2007/1/25, Felipe Monteiro de Carvalho :

Show quoted text 15 lines
On 1/25/07, Alexandre Leclerc wrote: > Yes, I understand that, but I *need* a scripting engine which is based > on Pascal. And ROPS is the only one I found that answered my > requirements. Also, it's integrated and it's "free", and very fast. > > If there was another way, I would use it. But since, I must rely on a > stable FPC internal to make it work. Does this script support other calling conventions? You could try using stdcall instead of register. It´s much simpler, and as stable as it can get. I remember writing a simple script engine myself, and then I choose to support mostly stdcall.

ROPS (RemObjects Pascal Script remobjects.com) is 100% pascal code that you simply use in your own code. The engine compiles in your application. It then work with the application stack, etc. to execute native pascal functions and script functions. Quite a nice script engine.

It works 100% with Delphi, but with FPC since the parameters are not the same order in the stactk, this causes issues. Right now I use the near 1 year old revision 3823 of FPC and it works ok for that revision. But after that it is not again. But I did not wanted to invest efforts to fix that before param-stack order is more 'stable' in FPC. Because I would have to work on it again later.

Alexandre Leclerc

Reply by email

Michael Van Canneyt
to Alexandre Leclerc
Alexandre Leclerc wrote 18 lines
2007/1/25, Felipe Monteiro de Carvalho : > On 1/25/07, Alexandre Leclerc wrote: > > Yes, I understand that, but I *need* a scripting engine which is based > > on Pascal. And ROPS is the only one I found that answered my > > requirements. Also, it's integrated and it's "free", and very fast. > > > > If there was another way, I would use it. But since, I must rely on a > > stable FPC internal to make it work. > > Does this script support other calling conventions? > > You could try using stdcall instead of register. It´s much simpler, > and as stable as it can get. > > I remember writing a simple script engine myself, and then I choose to > support mostly stdcall. ROPS (RemObjects Pascal Script remobjects.com) is 100% pascal code

Not 100%, there is 1 routine which is assembler, it's the routine that sets up the stack when making a call to an imported function.

that you simply use in your own code. The engine compiles in your application. It then work with the application stack, etc. to execute native pascal functions and script functions. Quite a nice script engine.

I use it since ages, even when it was not owned by remobjects.

Michael.

Reply by email

Alexandre Leclerc
to Michael Van Canneyt

2007/1/25, Michael Van Canneyt :

Show quoted text 25 lines
On Thu, 25 Jan 2007, Alexandre Leclerc wrote: > 2007/1/25, Felipe Monteiro de Carvalho : > > On 1/25/07, Alexandre Leclerc wrote: > > > Yes, I understand that, but I *need* a scripting engine which is based > > > on Pascal. And ROPS is the only one I found that answered my > > > requirements. Also, it's integrated and it's "free", and very fast. > > > > > > If there was another way, I would use it. But since, I must rely on a > > > stable FPC internal to make it work. > > > > Does this script support other calling conventions? > > > > You could try using stdcall instead of register. It´s much simpler, > > and as stable as it can get. > > > > I remember writing a simple script engine myself, and then I choose to > > support mostly stdcall. > > ROPS (RemObjects Pascal Script remobjects.com) is 100% pascal code Not 100%, there is 1 routine which is assembler, it's the routine that sets up the stack when making a call to an imported function.

Indeed, I did not think about that :) -- Since FPC compiles asembler, I almost tought it was pascal code :D

Alexandre Leclerc

Reply by email

Alexandre Leclerc
to Carlo Kok: You are right about that. There is a routine that does that, but all it does is copy the…

2007/1/26, Carlo Kok :

Show quoted text 48 lines
Michael Van Canneyt wrote: > > On Thu, 25 Jan 2007, Alexandre Leclerc wrote: > >> 2007/1/25, Felipe Monteiro de Carvalho : >>> On 1/25/07, Alexandre Leclerc wrote: >>>> Yes, I understand that, but I *need* a scripting engine which is based >>>> on Pascal. And ROPS is the only one I found that answered my >>>> requirements. Also, it's integrated and it's "free", and very fast. >>>> >>>> If there was another way, I would use it. But since, I must rely on a >>>> stable FPC internal to make it work. >>> Does this script support other calling conventions? >>> >>> You could try using stdcall instead of register. It´s much simpler, >>> and as stable as it can get. >>> >>> I remember writing a simple script engine myself, and then I choose to >>> support mostly stdcall. >> ROPS (RemObjects Pascal Script remobjects.com) is 100% pascal code > > Not 100%, there is 1 routine which is assembler, it's the routine > that sets up the stack when making a call to an imported function. > >> that you simply use in your own code. The engine compiles in your >> application. It then work with the application stack, etc. to execute >> native pascal functions and script functions. Quite a nice script >> engine. > > I use it since ages, even when it was not owned by remobjects. You are right about that. There is a routine that does that, but all it does is copy the prepared data onto the stack (And copy back the result). Now, there are a few problems with PS related to FPC: * FPC has changed default calling convention once (or twice?) * The way "register" works on FPC is slightly different from delphi, in delphi special types like interfaces, strings and variant results are passed as var parameters, it seems the easiest fix would be for me to change PascalScript to process results differently for FreePascal. How does FPC pass a string/variant/interface result actually? Returned in AEX? Once I know this, I should be able to add an FPCFIX define for this. (So it can be easily undone when FPC supports the same "Register" mode as Delphi does)

Carlo,

I was planning to build a small application to serve as a regression test (by testing some features of PS in FPC) in order to find quickly any problems. I was planning to do this in couple weeks. If this interest you, I can send you the code after so that it will become easier for you to test any feature that is broken in FPC.

Alexandre Leclerc

Reply by email

Carlo Kok
to Alexandre Leclerc
Alexandre Leclerc wrote 62 lines
2007/1/26, Carlo Kok : > Michael Van Canneyt wrote: > > > > On Thu, 25 Jan 2007, Alexandre Leclerc wrote: > > > >> 2007/1/25, Felipe Monteiro de Carvalho > : > >>> On 1/25/07, Alexandre Leclerc wrote: > >>>> Yes, I understand that, but I *need* a scripting engine which is > based > >>>> on Pascal. And ROPS is the only one I found that answered my > >>>> requirements. Also, it's integrated and it's "free", and very fast. > >>>> > >>>> If there was another way, I would use it. But since, I must rely > on a > >>>> stable FPC internal to make it work. > >>> Does this script support other calling conventions? > >>> > >>> You could try using stdcall instead of register. It´s much simpler, > >>> and as stable as it can get. > >>> > >>> I remember writing a simple script engine myself, and then I > choose to > >>> support mostly stdcall. > >> ROPS (RemObjects Pascal Script remobjects.com) is 100% pascal code > > > > Not 100%, there is 1 routine which is assembler, it's the routine > > that sets up the stack when making a call to an imported function. > > > >> that you simply use in your own code. The engine compiles in your > >> application. It then work with the application stack, etc. to execute > >> native pascal functions and script functions. Quite a nice script > >> engine. > > > > I use it since ages, even when it was not owned by remobjects. > > You are right about that. There is a routine that does that, but all it > does is copy the prepared data onto the stack (And copy back the > result). Now, there are a few problems with PS related to FPC: > > * FPC has changed default calling convention once (or twice?) > * The way "register" works on FPC is slightly different from delphi, in > delphi special types like interfaces, strings and variant results are > passed as var parameters, it seems the easiest fix would be for me to > change PascalScript to process results differently for FreePascal. > > How does FPC pass a string/variant/interface result actually? Returned > in AEX? > > > Once I know this, I should be able to add an FPCFIX define for this. (So > it can be easily undone when FPC supports the same "Register" mode as > Delphi does) Carlo, I was planning to build a small application to serve as a regression test (by testing some features of PS in FPC) in order to find quickly any problems. I was planning to do this in couple weeks. If this interest you, I can send you the code after so that it will become easier for you to test any feature that is broken in FPC.

Would be great.

Reply by email

Alexandre Leclerc
to Carlo Kok

2007/1/26, Carlo Kok :

Show quoted text 65 lines
Alexandre Leclerc wrote: > 2007/1/26, Carlo Kok : >> Michael Van Canneyt wrote: >> > >> > On Thu, 25 Jan 2007, Alexandre Leclerc wrote: >> > >> >> 2007/1/25, Felipe Monteiro de Carvalho >> : >> >>> On 1/25/07, Alexandre Leclerc wrote: >> >>>> Yes, I understand that, but I *need* a scripting engine which is >> based >> >>>> on Pascal. And ROPS is the only one I found that answered my >> >>>> requirements. Also, it's integrated and it's "free", and very fast. >> >>>> >> >>>> If there was another way, I would use it. But since, I must rely >> on a >> >>>> stable FPC internal to make it work. >> >>> Does this script support other calling conventions? >> >>> >> >>> You could try using stdcall instead of register. It´s much simpler, >> >>> and as stable as it can get. >> >>> >> >>> I remember writing a simple script engine myself, and then I >> choose to >> >>> support mostly stdcall. >> >> ROPS (RemObjects Pascal Script remobjects.com) is 100% pascal code >> > >> > Not 100%, there is 1 routine which is assembler, it's the routine >> > that sets up the stack when making a call to an imported function. >> > >> >> that you simply use in your own code. The engine compiles in your >> >> application. It then work with the application stack, etc. to execute >> >> native pascal functions and script functions. Quite a nice script >> >> engine. >> > >> > I use it since ages, even when it was not owned by remobjects. >> >> You are right about that. There is a routine that does that, but all it >> does is copy the prepared data onto the stack (And copy back the >> result). Now, there are a few problems with PS related to FPC: >> >> * FPC has changed default calling convention once (or twice?) >> * The way "register" works on FPC is slightly different from delphi, in >> delphi special types like interfaces, strings and variant results are >> passed as var parameters, it seems the easiest fix would be for me to >> change PascalScript to process results differently for FreePascal. >> >> How does FPC pass a string/variant/interface result actually? Returned >> in AEX? >> >> >> Once I know this, I should be able to add an FPCFIX define for this. (So >> it can be easily undone when FPC supports the same "Register" mode as >> Delphi does) > > Carlo, > > I was planning to build a small application to serve as a regression > test (by testing some features of PS in FPC) in order to find quickly > any problems. I was planning to do this in couple weeks. If this > interest you, I can send you the code after so that it will become > easier for you to test any feature that is broken in FPC. > Would be great.

Good, I contact you once it's done (to this email address, if you permit me).

Alexandre Leclerc

Reply by email