[fpc-devel]I suggest a new FPC feature
Jonas Maebe
jonas at zeus.rug.ac.be
Fri Oct 12 13:49:24 CEST 2001
On vrijdag, oktober 12, 2001, at 01:32 , Pavel V. Ozerski wrote:
> The functionality is also not always the same: if inside "fpc stdcall"
> procedure something will change
> these three registers, it will not always cause appliction crash
> because they will be retored before return.
> Procedures/functions having default calling conventions and compiled
> with FPC or procedures/functions
> declared as stdcall but compiled with Delphi are potentially more
> dangerous. "FPC stdcall" is something
> middle between "Delphi stdcall" and safecall. I'm concordant with you,
> the functionality under normal conditions
> is the same. But the situation with stdcall constructors demonstrates
> that the difference can be important somewhere.
That procedures/functions with the default calling convention are
incompatible between Delphi and FPC, is true. Not only due to the
differences in register saving, but also due to differences in parameter
passing (Delphi supports register parameters, FPC doesn't (yet)). I
think that's exactly the reason why you can specify calling conventions.
However, when declaring them as stdcall, they should be compatible.
Delphi should save ebx/esi/edi if they're modified (and I think
assembler statements don't count, just like FPC's assembler parser,
Delphi's parser probably also doesn't try to "understand" the assembler
code).
The fact that there are problems with stdcall constructors under FPC, is
just that the popped esi at the end overwrites the pointer to the
generated object (which is normally returned in esi) I think. So we
should indeed reject cdecl/stdcall/... for constructors.
Jonas
More information about the fpc-devel
mailing list