64 bits and PascalScript

[domasz]

Is there a problem with Pascal Script in 64 bits? 32 bit Lazarus runs the same code using Pascal Script just fine. 64 bit Lazarus crashes in weird places.

[Martin_fr]

I can't recall any from the top of my head.

But it may well depend on what data types you use.

Also, it may depend on which (and how) access to your compiled code you setup.
- callbacks use some asm to emulate calls. that code is different for each cpu / bitness
- events between script and compiled app only work for some cpu

[LV]

There is certainly an issue:

https://forum.lazarus.freepascal.org/index.php/topic,70668

https://forum.lazarus.freepascal.org/index.php/topic,70535

https://forum.lazarus.freepascal.org/index.php/topic,68442

[domasz]

Thanks, @LV!

[maurog]

I use PascalScript in LazCAD and have successfully compiled and run it on both Linux and Windows (64-bit). The application runs smoothly without any crashes. However, in form (GUI) scripts, the event handler routines – such as Button1.OnClick – are not executed.

[jamie]

I guess the question is, is it actually executing the events and are they executing 32-bit versions of the address?

I think using 32-bit addresses wouldn't play well in a 64-bit system.

[maurog]

@jamie
I’ve just compiled and run my application in 32-bit mode on Windows 7 64-bit, and now the events are being triggered correctly.

So it works!

This leads me to believe that PascalScript indeed uses 32-bit method pointers internally, which causes problems when running in 64-bit mode — especially for event handlers (like OnClick).

Thanks a lot for the helpful hints and confirmations!

Best regards,
Maurog

[Thaddy]

That does not take away that really there should be, at one point, an effort to de-32bit the code. I don't use Pascal script anymore, so count me out.

[jamie]

@jamie
I’ve just compiled and run my application in 32-bit mode on Windows 7 64-bit, and now the events are being triggered correctly.

So it works!

This leads me to believe that PascalScript indeed uses 32-bit method pointers internally, which causes problems when running in 64-bit mode — especially for event handlers (like OnClick).

Thanks a lot for the helpful hints and confirmations!

Best regards,
Maurog

 The point I was trying to make is that in 64-bit mode it still maybe constructing the event address to call the method however, it could be cutting off the upper 32-bit part and there for could be calling some even code in la la land.

 This obviously would be cause for alarm.

[maurog]

I'm using Pascal Script as a runtime scripting engine in LazCAD, and I originally planned to develop a form designer for creating script-based interfaces. However, due to the issue mentioned above – namely, that events are not being triggered correctly – I’ve put the project on hold for now.

Now I’m faced with a decision: Should I take a closer look at Pascal Script and try to make it 64-bit compatible, even though I have limited experience in that area? Or would it be more reasonable to switch to a different scripting language? (In that case, I would also need to adapt the CAD scripting interface.)

Which of the two options would involve less effort overall? And if switching turns out to be the better path – which alternative scripting language would you recommend?

Thanks a lot!
Maurog-

[Martin_fr]

I have a distant memory that event were simple not implemented for all bitness/cpu combinations.
But a recent look at the IFDEF blocks says they are (or well at least the code seems to be "not empty").

In any case you will most likely find that the issue is in "simulating the call" to the procedure.

Any call (event or otherwise) needs to pass the parameters. Some need to be in CPU registers, others need to be on the stack, possible with specific alignments. (depends also on calling convention)

Newer versions of Delphi have some API to make calls using RTTI... I don't know what is avail in FPC 3.3.1 (and I heard somewhere it may need some so/dll - but I may have mistaken something else).

Anyway, afaik, the script engine does not make use of this in FPC.

Instead the script engine "builds" the callstack itself. That requires assembler code, as it needs to set the correct cpu registers.

There is an inc file for each CPU, if you want to look at it...


I don't recall exactly, but I may have had some issues with that even in normal procedure/methods calls... Not sure, could be the got fixed.
Anyway, the more architectures were to be supported, the more risky this approach is. Because you need to test a ton of different calls (with different mix of parameters by type and order) for each of them.

PascalScript offers a 2nd way:
    RegisterMethodName
    RegisterPropertyNameHelper
(the version in Lazarus has more of this than the original)

This register a function that doesn't get called with the parameters directly as given by the caller.

E.g. if the caller does
    Foo(1,'abc')

then the registered method does not get an integer and a string.
It gets a "TPSStack" object. And that will have 2 entries that you can get as int/string (or as TPSVariant... which you will need e.g. for enum).

The advantage: It doesn't need the per-CPU asm stuff. The method signature is known at compile time, and it is a normal method call generated by the compiler.

But afaik that doesn't exist for events ....

[LV]

If you develop a graphical interface on the host program side, it is quite simple and works reliably in both 32-bit and 64-bit operating systems. Below is a minimal working example. The main script is running, calculating values, interacting with GUI elements, and generating graphs. A user script processes the event of pressing the Plot Settings button.
Enjoy 

Updated: In the project1 object inspector, the DejaVu Sans Mono font is set for SynEdit1 and Memo1. If this font is missing  , set an available font for correct display. For cross-platform support, you can add the code:

Code: Pascal  [Select][+][-]

1. const
2.   {$IFDEF MSWINDOWS}
3.     TARGET_FONT = 'Consolas';
4.   {$ENDIF}
5.   {$IFDEF LINUX}
6.     TARGET_FONT = 'DejaVu Sans Mono';
7.   {$ENDIF}
8.  
9. ...
10. ...
11. ...
12.  
13. SynEdit1.Font.Name := TARGET_FONT;
14. Memo1.Font.Name := TARGET_FONT;
15.  

[maurog]

@LV
Thanks for the example. What I mean is the following:
The example script below works correctly when the host application is 32-bit.
However, if the host is 64-bit, the button click is not detected or executed:

Code: Pascal  [Select][+][-]

1. var Form1: TForm;
2.     Button1: TButton;
3.     Memo1: TMemo;
4.  
5.  
6. procedure  OnButton1Click(Sender: TObject);
7. begin
8.   Memo1.Text := '';
9.   Memo1.Text := 'Button1Click';
10. end;
11.  
12. begin
13.   Form1 := TForm.Create(nil);
14.   Button1 := TButton.Create(Form1);
15.   Button1.Parent := Form1;
16.   Button1.OnClick := @OnButton1Click;
17.   Memo1 := TMemo.Create(Form1);
18.   Memo1.Top := 50;
19.   Memo1.Parent := Form1;
20.   Form1.Show;
21. end.            
22.  

[LV]

However, if the host is 64-bit, the button click is not detected or executed

For this reason, I refused to create a GUI on the script side in 64-bit applications. Pascal Script is used to save and then run the host program, which includes many settings for initial and boundary conditions of modeling, saving intermediate results at specified times, and data visualization, among other features. In other words, the user does not need to enter a lot of initial data and settings; he just runs the script, which is useful when performing serial calculations.

[LV]

However, if the host is 64-bit, the button click is not detected or executed

For this reason, I refused to create a GUI on the script side in 64-bit applications.

I changed my mind. Compile and run the attached project. 


“Talk is cheap. Show me the code.”
— Linus Torvalds