It does not matter if I compile it with stdcall, cdecl, pascal. The below on a 32 bit intel mac (fpc 2.6.0) always returns result in 2 registers (eax, edx)

Is there a way to change this (some declaration in the source, some switch)?

function Point(AX, AY: Integer): TPoint;
begin
   with Result do
   begin
     X := AX;
     Y := AY;
   end;
end;

Background. I am trying to get PascalScript to work. But it doesnt knom about edx. And I don't know enough about it and/or calling convention to change pascalscript (within the amount of time, I can currently set aside for this)

Martin wrote

It does not matter if I compile it with stdcall, cdecl, pascal. The below on a 32 bit intel mac (fpc 2.6.0) always returns result in 2 registers (eax, edx) Is there a way to change this (some declaration in the source, some switch)?

It's a bug that's fixed in trunk: http://wiki.freepascal.org/User_Changes_Trunk#Location_of_certain_function_result_types

Jonas

As the author of pascalscript, I wasn't aware of this issue, however now I'm in a dilemma. FPC breaks things very often, and that url shows just one of these. If I want to fix this bug in Pascal Script, I have to undo the fix in 6-12 months again (or use version specific defines). I'm getting a bit frustrated with FPC changing things back and forward all the time (this isn't a new thing, this has been going on since I first ported it to FPC).

It's not useful to talk in general terms when discussing specific issues. Would you have preferred that this particular bug had remained in the compiler, in the interest of backward compatibility?

Additionally, the URL does not just show "one of these", but a "bunch of those". We do our best to document every such case, and always in the same place on the wiki.

If I want to fix this bug in Pascal Script, I have to undo the fix in 6-12 months again (or use version specific defines).

The correct fix is indeed an version-specific define.

I'm getting a bit frustrated with FPC changing things back and forward all the time (this isn't a new thing, this has been going on since I first ported it to FPC).

"back and forward" suggests that we change it in one way in one version, and then back again to the old behaviour in a successive version. Afaik that has never happened until now. We do occasionally fix bugs that break backward compatibility, but as explained above I don't see an alternative to leaving in such bugs forever.

Jonas

As the author of pascalscript, I wasn't aware of this issue, however now I'm in a dilemma. FPC breaks things very often, and that url shows just one of these.

It's not useful to talk in general terms when discussing specific issues. Would you have preferred that this particular bug had remained in the compiler, in the interest of backward compatibility?

I suppose you're right. I'm just frustrated.

Oke.

The constructor call abi was changed twice (1 or 2 years ago), the last change undid the first. That said, yes, you are right, bugs should be fixed. I'd just like to be able to say "it works with all these versions", instead of specific ones.

Carlo Kok wrote

The constructor call abi was changed twice (1 or 2 years ago), the last change undid the first.

I don't remember that one. Was that across released FPC versions?

That said, yes, you are right, bugs should be fixed. I'd just like to be able to say "it works with all these versions", instead of specific ones.

Well, depending on machine level compiler-implementation detail is the ideal recipe for trouble, no matter how useful the result may be. And while normally calling convention-related stuff would almost never change because it would break all interfacing with dynamic libraries compiled by previous FPC versions, in practice such FPC-compiled libraries are (fortunately) not in widespread distribution or use and hence we can still fix such bugs.

External review or rigorous testing of the calling convention code in all possible scenarios could also help with getting everything fixed in one release, instead of piecemeal one change at a time.

Jonas