Sign in Join

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

Mailing lists / lazarus / 2012-09

PascalScript on Win x64

16 messages · 7 people · –

Reply by email Subscribe to this list Your subscription

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

Alexander Hofmann

Hi there.

This is a cross-post (cross-mail ?) to
http://www.lazarus.freepascal.org/index.php/topic,17978.0.html as I got the hint there that it might be better to ask on the list instead of in the forum, at least concerning the calling conventions - but I'll ask the whole lot, anyway; I hope that's ok.

Has anyone successfully used PascalScript with Lazarus Classes (e.g. TForm, TButton) on Win x64?

I can compile the downloadable latest stable version from RemObject's website (the one with the EXE-Installer) as well as the latest development version from https://github.com/remobjects/pascalscript OR (that's not in the Forum) the PascalScript-version included in Lazarus' SVN, no Problem there, after two small changes in x64.inc (see below). Running the script works, adding user defined functions (and calling them!) is OK, too.

But as soon as I try to Create forms and objects, like the following script, the Program crashes with a SIGSEGV.

|program Script;
var
  f:TForm;
  b:TButton;
begin
  f:=TForm.CreateNew(nil); //<- Works
  b:=TButton.Create(f); //<- crash
  b.Parent:=f;
  f.Show;
end.|

Crash in the Program is here:

|CLASSES_TCOMPONENT_$__INSERTCOMPONENT$TCOMPONENT
000000000044F900 4883ec38 sub $0x38,%rsp 000000000044F904 48895c2420 mov %rbx,0x20(%rsp) 000000000044F909 4889742428 mov %rsi,0x28(%rsp) 000000000044F90E 4889cb mov %rcx,%rbx 000000000044F911 4889d6 mov %rdx,%rsi 000000000044F914 4889da mov %rbx,%rdx 000000000044F917 4889f1 mov %rsi,%rcx 000000000044F91A 4889f0 mov %rsi,%rax 000000000044F91D 488b00 mov (%rax),%rax 000000000044F920 ff9068010000 callq *0x168(%rax) <-- crash|

Am I doing anything wrong? The same Script runs fine when the Application was compiled with x86 Lazarus 1.0.
By the way: creating a TObject with e.g. o:=TObject.Create doesn't break at al.

Interestingly, when I start debugging
<SomeClass>.Create(aOwner:TComponent)-Type of Constructors, there is some difference in the Register values, depending on whether the Constructor was called from "pure" FPC-Code or the Script (at least so it seems):
o Called from FPC: rcx: 0 (nil), rdx: Class Reference, r8: Value of aOwner o Called from Script: rcx: Class Reference, rdx: 1 (!?), r8: Value of aOwner (at least so it seems)

Is there any difference in the calling convention on x64-Systems between Delphi and Lazarus? I could only find the "standard" information on Windows x64 calling conventions, without special care of constructors, if there is any...

Did anybody else stumble about that problem before? Thanks for your help!

Index: x64.inc
=================================================================== --- x64.inc (revision 38441)
+++ x64.inc (working copy)
@@ -14,7 +14,7 @@

   _RCX, _RDX, _R8, _R9: IPointer;
   var _XMM0: Double;
   _XMM1, _XMM2, _XMM3: Double;

- aStack: Pointer; aItems: IntPtr); assembler; {$IFDEF FPC}nostackframe;{$ENDIF}
+ aStack: Pointer; aItems: PtrUInt); assembler; {$IFDEF FPC}nostackframe;{$ENDIF}
asm
(* Registers:
RCX: Address
@@ -37,7 +37,7 @@
mov rdx, aStack
jmp @compareitems
@work:
- push [rdx]
+ push qword ptr [rdx]
dec rcx
sub rdx,8
@compareitems:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120904/a274ad29/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120904/a274ad29/attachment-0001.bin>

Reply by email

Martin
to Alexander Hofmann: Hi there. This is a cross-post (cross-mail ?) to…
Alexander Hofmann wrote 7 lines
Hi there. This is a cross-post (cross-mail ?) to http://www.lazarus.freepascal.org/index.php/topic,17978.0.html as I got the hint there that it might be better to ask on the list instead of in the forum, at least concerning the calling conventions - but I'll ask the whole lot, anyway; I hope that's ok.

As Vincent pointed out. FPC mailinglist.

Show quoted text 15 lines
Interestingly, when I start debugging <SomeClass>.Create(aOwner:TComponent)-Type of Constructors, there is some difference in the Register values, depending on whether the Constructor was called from "pure" FPC-Code or the Script (at least so it seems): o Called from FPC: rcx: 0 (nil), rdx: Class Reference, r8: Value of aOwner o Called from Script: rcx: Class Reference, rdx: 1 (!?), r8: Value of aOwner (at least so it seems) Is there any difference in the calling convention on x64-Systems between Delphi and Lazarus? I could only find the "standard" information on Windows x64 calling conventions, without special care of constructors, if there is any...

You will be able to get an answer about the calling convention fpc uses (They should be standard)

But you can then check yourself in x64.inc what PascalScript does.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120904/55e4017d/attachment.html>

Reply by email

Sven Barth
to Martin
Martin wrote 30 lines
On 04/09/2012 13:24, Alexander Hofmann wrote: > Hi there. > > This is a cross-post (cross-mail ?) to > http://www.lazarus.freepascal.org/index.php/topic,17978.0.html as I > got the hint there that it might be better to ask on the list instead > of in the forum, at least concerning the calling conventions - but > I'll ask the whole lot, anyway; I hope that's ok. As Vincent pointed out. FPC mailinglist. > > Interestingly, when I start debugging > <SomeClass>.Create(aOwner:TComponent)-Type of Constructors, there is > some difference in the Register values, depending on whether the > Constructor was called from "pure" FPC-Code or the Script (at least so > it seems): > o Called from FPC: rcx: 0 (nil), rdx: Class Reference, r8: Value of aOwner > o Called from Script: rcx: Class Reference, rdx: 1 (!?), r8: Value of > aOwner (at least so it seems) > > Is there any difference in the calling convention on x64-Systems > between Delphi and Lazarus? I could only find the "standard" > information on Windows x64 calling conventions, without special care > of constructors, if there is any... > You will be able to get an answer about the calling convention fpc uses (They should be standard) But you can then check yourself in x64.inc what PascalScript does.

This seems to be the main disadvantage of PascalScript: it needs platform specific assembler code...

Perhaps the situation can be improved once Rtti.Invoke ( http://docwiki.embarcadero.com/Libraries/de/System.Rtti.Invoke ) is implemented...

Regards,
Sven

Reply by email

Martin
to Sven Barth
Sven Barth wrote 8 lines
This seems to be the main disadvantage of PascalScript: it needs platform specific assembler code... Perhaps the situation can be improved once Rtti.Invoke ( http://docwiki.embarcadero.com/Libraries/de/System.Rtti.Invoke ) is implemented...

I doubt it.

RTTI may (you need to establish if this applies to *all* cases) tell you that "procedure Foo(a: integer)" takes 1 int param. But it will not tell you, if this needs to be on the stack, or in a register (or which register).

Reply by email

Martin
to Martin
Martin wrote 17 lines
On 04/09/2012 14:02, Sven Barth wrote: > > This seems to be the main disadvantage of PascalScript: it needs > platform specific assembler code... > > Perhaps the situation can be improved once Rtti.Invoke ( > http://docwiki.embarcadero.com/Libraries/de/System.Rtti.Invoke ) is > implemented... > I doubt it. RTTI may (you need to establish if this applies to *all* cases) tell you that "procedure Foo(a: integer)" takes 1 int param. But it will not tell you, if this needs to be on the stack, or in a register (or which register).

Sorry, not correct. It does: in calling convention.

The point I meant to made is: you still need to get the value into that register, or set up the stack. That can only be done in asm

Reply by email

Henry Vermaak
to Martin
Martin wrote
The point I meant to made is: you still need to get the value into that register, or set up the stack. That can only be done in asm

No, you don't need to do anything. Invoke calls the function with the supplied "Args", which is exactly what the assembler code in pascalscript does.

Henry

Reply by email

Sven Barth
to Martin: Sorry, not correct. It does: in calling convention. The point I meant to made is: you…
Martin wrote 23 lines
On 04/09/2012 14:41, Martin wrote: > On 04/09/2012 14:02, Sven Barth wrote: >> >> This seems to be the main disadvantage of PascalScript: it needs >> platform specific assembler code... >> >> Perhaps the situation can be improved once Rtti.Invoke ( >> http://docwiki.embarcadero.com/Libraries/de/System.Rtti.Invoke ) is >> implemented... >> > > I doubt it. > > RTTI may (you need to establish if this applies to *all* cases) tell you > that "procedure Foo(a: integer)" takes 1 int param. > But it will not tell you, if this needs to be on the stack, or in a > register (or which register). > Sorry, not correct. It does: in calling convention. The point I meant to made is: you still need to get the value into that register, or set up the stack. That can only be done in asm

Yes, it can only be done in ASM, but the Invoke function is part of the RTL and thus would by definition be available for all platforms supported by FPC (even if not every platform would be available at once).

Regards,
Sven

Reply by email

Alexander Hofmann
to Vincent Snijders: 2012/9/4 Alexander Hofmann : The fpc mailing list was suggested. For more info see:…
Vincent Snijders wrote 9 lines
2012/9/4 Alexander Hofmann : > Hi there. > > This is a cross-post (cross-mail ?) to > http://www.lazarus.freepascal.org/index.php/topic,17978.0.html as I got the > hint there that it might be better to ask on the list instead of in the > forum, at least concerning the calling conventions - The fpc mailing list was suggested. For more info see: http://www.freepascal.org/maillist.var

Erm. Your're right, of course... I'm sorry for that..

Thanks for the hint.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120904/fbc942c4/attachment.bin>

Reply by email

Paul Ishenin
to Sven Barth: Yes, it can only be done in ASM, but the Invoke function is part of the RTL and thus…

04.09.12, 22:10, Sven Barth ?????:

Show quoted text 24 lines
>>> This seems to be the main disadvantage of PascalScript: it needs >>> platform specific assembler code... >>> >>> Perhaps the situation can be improved once Rtti.Invoke ( >>> http://docwiki.embarcadero.com/Libraries/de/System.Rtti.Invoke ) is >>> implemented... >>> >> >> I doubt it. >> >> RTTI may (you need to establish if this applies to *all* cases) tell you >> that "procedure Foo(a: integer)" takes 1 int param. >> But it will not tell you, if this needs to be on the stack, or in a >> register (or which register). >> > > Sorry, not correct. It does: in calling convention. > > The point I meant to made is: you still need to get the value into that > register, or set up the stack. That can only be done in asm Yes, it can only be done in ASM, but the Invoke function is part of the RTL and thus would by definition be available for all platforms supported by FPC (even if not every platform would be available at once).

Maybe at the first step to move the code for invokation of FPC methods from PascalScript code into a LCL unit (if license allows) - so later it will be simple moved to FPC RTL?

Best regards,
Paul Ishenin

Reply by email

Sven Barth
to Paul Ishenin
Paul Ishenin wrote 31 lines
04.09.12, 22:10, Sven Barth ?????: >>>> This seems to be the main disadvantage of PascalScript: it needs >>>> platform specific assembler code... >>>> >>>> Perhaps the situation can be improved once Rtti.Invoke ( >>>> http://docwiki.embarcadero.com/Libraries/de/System.Rtti.Invoke ) is >>>> implemented... >>>> >>> >>> I doubt it. >>> >>> RTTI may (you need to establish if this applies to *all* cases) tell >>> you >>> that "procedure Foo(a: integer)" takes 1 int param. >>> But it will not tell you, if this needs to be on the stack, or in a >>> register (or which register). >>> >> >> Sorry, not correct. It does: in calling convention. >> >> The point I meant to made is: you still need to get the value into that >> register, or set up the stack. That can only be done in asm > > Yes, it can only be done in ASM, but the Invoke function is part of the > RTL and thus would by definition be available for all platforms > supported by FPC (even if not every platform would be available at once). Maybe at the first step to move the code for invokation of FPC methods from PascalScript code into a LCL unit (if license allows) - so later it will be simple moved to FPC RTL?

If the license allows it this might be an interesting idea. The most important thing that is missing is the TValue type and also I don't know how the Invoke code knows if the pointer passed in is a global one, a method, a class method or a static method...

Regards,
Sven

Reply by email

Martin
to Paul Ishenin: 04.09.12, 22:10, Sven Barth ?????: Maybe at the first step to move the code for…
Paul Ishenin wrote 9 lines
> Yes, it can only be done in ASM, but the Invoke function is part of the > RTL and thus would by definition be available for all platforms > supported by FPC (even if not every platform would be available at > once). Maybe at the first step to move the code for invokation of FPC methods from PascalScript code into a LCL unit (if license allows) - so later it will be simple moved to FPC RTL?

Would have to check, but probably not needed.

The license allows us to ship a copy of the entire package (afaik also a modified one, if we point out that it is modified.) We already do (because soon the IDE itself will use it.

So we can patch that.

Reply by email

Paul Ishenin
to Martin

06.09.12, 17:36, Martin ?????:

Show quoted text 18 lines
On 06/09/2012 03:40, Paul Ishenin wrote: > >> Yes, it can only be done in ASM, but the Invoke function is part of the >> RTL and thus would by definition be available for all platforms >> supported by FPC (even if not every platform would be available at >> once). > > Maybe at the first step to move the code for invokation of FPC methods > from PascalScript code into a LCL unit (if license allows) - so later > it will be simple moved to FPC RTL? Would have to check, but probably not needed. The license allows us to ship a copy of the entire package (afaik also a modified one, if we point out that it is modified.) We already do (because soon the IDE itself will use it. So we can patch that.

But can we later copy that code to FPC?

Best regards,
Paul Ishenin

Reply by email

Martin
to Paul Ishenin
Paul Ishenin wrote 9 lines
> Would have to check, but probably not needed. > > The license allows us to ship a copy of the entire package (afaik also a > modified one, if we point out that it is modified.) > We already do (because soon the IDE itself will use it. > > So we can patch that. But can we later copy that code to FPC?

You mean use Invoke, when avail?
Could do. I would hope that this would be done upstream by REM objects.

I can not "copy" anything to fpc, I have no commit rights there. Besides it is not my decision what goes into fpc.

Reply by email

Sven Barth
to Martin
Martin wrote 16 lines
On 06/09/2012 11:02, Paul Ishenin wrote: >> Would have to check, but probably not needed. >> >> The license allows us to ship a copy of the entire package (afaik also a >> modified one, if we point out that it is modified.) >> We already do (because soon the IDE itself will use it. >> >> So we can patch that. > > But can we later copy that code to FPC? You mean use Invoke, when avail? Could do. I would hope that this would be done upstream by REM objects. I can not "copy" anything to fpc, I have no commit rights there. Besides it is not my decision what goes into fpc.

The main problem of "can we copy" is the license. The RTL is released as modified LGPL so we must be able to release that calling code under modified LGPL as well.

But some part of the code needs to be changed nevertheless so it can become a correct implementation of RTTI.Invoke...

Regards,
Sven

Reply by email

Joost van der Sluis
to Sven Barth: If the license allows it this might be an interesting idea. The most important thing that…
Sven Barth wrote 27 lines
Am 06.09.2012 04:40, schrieb Paul Ishenin: > 04.09.12, 22:10, Sven Barth ?????: > >>>> RTTI may (you need to establish if this applies to *all* cases) tell >>>> you >>>> that "procedure Foo(a: integer)" takes 1 int param. >>>> But it will not tell you, if this needs to be on the stack, or in a >>>> register (or which register). >>>> >>> >>> Sorry, not correct. It does: in calling convention. >>> >>> The point I meant to made is: you still need to get the value into that >>> register, or set up the stack. That can only be done in asm >> >> Yes, it can only be done in ASM, but the Invoke function is part of the >> RTL and thus would by definition be available for all platforms >> supported by FPC (even if not every platform would be available at once). > > Maybe at the first step to move the code for invokation of FPC methods > from PascalScript code into a LCL unit (if license allows) - so later it > will be simple moved to FPC RTL? If the license allows it this might be an interesting idea. The most important thing that is missing is the TValue type and also I don't know how the Invoke code knows if the pointer passed in is a global one, a method, a class method or a static method...

Please take a look at the
http://svn.freepascal.org/svn/fpc/branches/joost/classattributes branch. It contains an initial implementation of the TValue type. I still have to add some testcases and tidy thins up and then this can be merged to trunk.

Adding invocation to fpc's RTTI isn't that hard, only quite some work to implement on all platforms.

Joost.

Reply by email