Pascal + AxRuntime

[magorium]

That's a handy website

Everything to keep the crowd happy 

But on a more serious note: it is there for those that do not wish/want to be bothered by installing the Free Pascal Compiler. It is very helpful in case you wish to try out a) the Free Pascal Compiler, or b) have difficulty installing/configuring the binutils (which tbh is a pain todo for all supported platforms).

Very handy in case you are at a location with too much restrictions, or to simply ab(use) in case you (quickly) wish to try out some idea.

Indeed programs now work correctly 

Good !

I am able to confirm that when you compile the Free Pascal Compiler from trunk, that it also has this issue fixed. Thank you ALB42 !!.

Happy programming !

[deadwood]

I am able to confirm that when you compile the Free Pascal Compiler from trunk, that it also has this issue fixed. Thank you ALB42 !!.

Happy programming !

Do you know where to find re-compiled "bigger" programs? It would be great to get MCAmiga or Leu to fully re-test small code model changes I did.

[deadwood]

@magorium

I pushed updates to alt-runtime branch.

1) SetMem_SSE fix
2) __kick_start now returns control to calling function, see https://github.com/deadw00d/AROS/commit/69b64d6310fe9294c272319a858af2a0a603212b

Please update and do a clean rebuild.

[magorium]

Do you know where to find re-compiled "bigger" programs? It would be great to get MCAmiga or Leu to fully re-test small code model changes I did.

PM send 

ALB42 just needs some time to update. It could even be he waits for the next release of each individual program. The T100pUAD distro contains almost all his programs and afaik has the most chance of being updated more quickly. Not sure about it though.


Please let me know of the files from the pm work for you or not (i haven't had a chance to test myself yet).

[deadwood]

Thanks for the builds. They don't crash anymore at open. MCAmiga seems to work with -m 640. Leu however has some problems and is not opening an empty spreadsheet unlike when run with -m 480.

[deadwood]

Ok, another issue to report Try copying C:AddAudioModes to RAM: and you will get a crash (with -m 640)

Code: [Select]

#0  0x0000000060144b4d in Dos_76_SetFileSize (file=0xffffffffef762390, offset=0, mode=-1)
    at /ssd/deadwood/repo-github-dd-core/AROS/rom/dos/./setfilesize.c:55
#1  0x00000000413ddcc8 in SYSUTILS_$$_FILECREATE$RAWBYTESTRING$$INT64 ()
#2  0x00007fffefd2b800 in ?? ()
#3  0x00007fffefd1b3d0 in ?? ()
#4  0x00007fffefd1b4c8 in ?? ()
#5  0x0000000000000001 in ?? ()
#6  0x00007fffefd25b80 in ?? ()
#7  0x00007fffefd1b570 in ?? ()
#8  0x00007fffefd2b800 in ?? ()
#9  0x00007fffefc1c090 in ?? ()
#10 0x0000000000000000 in ?? ()
(gdb)

Looks like the same BPTR issue (see file argument)

[magorium]

Thanks for the builds. They don't crash anymore at open. MCAmiga seems to work with -m 640. Leu however has some problems and is not opening an empty spreadsheet unlike when run with -m 480.

Thank you for reporting back. I'm currently building the new axrt and will later investigate the issue with regards to Leu.

[deadwood]

BTW, check this out

https://ae.amigalife.org/index.php?topic=561.105.msg10207#msg10207

[magorium]

Ok, another issue to report Try copying C:AddAudioModes to RAM: and you will get a crash (with -m 640)

Code: [Select]

#0  0x0000000060144b4d in Dos_76_SetFileSize (file=0xffffffffef762390, offset=0, mode=-1)
    at /ssd/deadwood/repo-github-dd-core/AROS/rom/dos/./setfilesize.c:55
#1  0x00000000413ddcc8 in SYSUTILS_$$_FILECREATE$RAWBYTESTRING$$INT64 ()
#2  0x00007fffefd2b800 in ?? ()
#3  0x00007fffefd1b3d0 in ?? ()
#4  0x00007fffefd1b4c8 in ?? ()
#5  0x0000000000000001 in ?? ()
#6  0x00007fffefd25b80 in ?? ()
#7  0x00007fffefd1b570 in ?? ()
#8  0x00007fffefd2b800 in ?? ()
#9  0x00007fffefc1c090 in ?? ()
#10 0x0000000000000000 in ?? ()
(gdb)

Looks like the same BPTR issue (see file argument)

Should be fixed. Thanks to ALB42, see https://gitlab.com/freepascal.org/fpc/source/-/commit/07ff5f423abb1107be587bbb1edb55e840017b5c

This whole 64-bit-me-thingy  seems to turn out very beneficial for both your and our end 

Thank you for reporting.

[magorium]

@magorium

I pushed updates to alt-runtime branch.

1) SetMem_SSE fix
2) __kick_start now returns control to calling function, see https://github.com/deadw00d/AROS/commit/69b64d6310fe9294c272319a858af2a0a603212b
Please update and do a clean rebuild.

Thank you.

I've updated and tested a little.  Things seem to work for me like a charm 

I really like the fact that my Pascal programs now can shut down properly (it makes me sleep better at nights) 

That also means that i can start cleaning up some code and create some specific Pascal units for axrt (but not before documenting some Pascal related stuff).

BTW, check this out https://ae.amigalife.org/index.php?topic=561.105.msg10207#msg10207

Ah, nice !

Tat is why we do it, not ? Thank you for sharing deadwood.

[deadwood]

This whole 64-bit-me-thingy  seems to turn out very beneficial for both your and our end 

Win-win. That's how it should be. 

[OlafS3]

This whole 64-bit-me-thingy  seems to turn out very beneficial for both your and our end 

Win-win. That's how it should be. 

Great 

By this development on AxRuntime will benefit both the AxRuntime branch and Aros 64bit

thanks

[deadwood]

@magorium

Can you point ALB42 to this thread https://ae.amigalife.org/index.php?topic=881.0.msg10235#msg10235 and this commit https://github.com/deadw00d/AROS/commit/b9bc67accce27db0e2cc0f79f554dc76e9b17a73? A change is needed in AROS Pascal units. This is triggered by functionality of running AROS x86_64 binaries  under AxRuntime.

[magorium]

@deadwood

Thank you for pointing that out, and i shall forward it (in case ALB did not read it himself yet).

Speaking of which, he made some other changes with regards to 64 bit AROS compatibility for FPC as wel, see https://gitlab.com/freepascal.org/fpc/source/-/commit/f1cf83bd8a2ff5b38a4fa5ecb6e2f8e102d8b372

I am a bit confused though so maybe you can clear that up for me ?

In your commit you state state it doesn't affect FPC. I'll look into it if it actually does or not but besides that (because it is a breaking change): does this change (in the end, because i am still a bit confused about the workflow that is done right now) affect all 64 bit AROS ? e.g. official aros.org builds, your build and axruntime ?

BTW, sorry for the delay as i wanted to update the FPC testfiles you downloaded, but i was unable to update them yet. Unfortunately i had some other (unforeseen) obligations this weekend :-/

[deadwood]

In your commit you state state it doesn't affect FPC. I'll look into it if it actually does or not but besides that (because it is a breaking change): does this change (in the end, because i am still a bit confused about the workflow that is done right now) affect all 64 bit AROS ? e.g. official aros.org builds, your build and axruntime ?

What I wanted to say is that this change does not affect current applications that I tested, so there is no immediate need for re-compilation. It might be just luck that applications don't access the effected fields of affected structures.

As for second part of your question: this change was already present in AxRuntime from beginning and now its synchronized to ABIv11. It will not make it to official aros.org build - it's specific to my builds.