[fpc-devel] constref in Windows

[Jonas Maebe]

On 20 Nov 2010, at 12:21, Paul Ishenin wrote:

> 20.11.2010 17:53, Jonas Maebe wrote:
>> Also, the default calling convention on non-x86 platforms is supposed to be compliant with the default ABI of the platform. Many of these platforms pass small records all by value (const or not).
> 
> Const is a pascal keyword which can mean for pascal "pass records by reference".

Making it mean that would make a lot of code less efficient. It doesn't have that meaning for the i386 "register" calling convention either (and it cannot be made to mean that there, because that would break Delphi compatibility).

> If you need to pass a record by value to some system C routine then don't mark that argument as const during the header convertion. What is wrong?

A few things are being mixed here:
1) all C header translations have to mark the imported routines as "cdecl", and cdecl, cppdecl and mwpascal are the only calling convention where "const" has a defined meaning in FPC as far as how a parameter is passed (namely "by value" for cdecl and cppdecl, because in C/C++ a "const" parameter is also passed by value; and for mwpascal it's "by value, except for records which are passed "by reference", because that's how MetroWerks Pascal does it -- i.e., another "solution" could be to define the interface helper methods as "mwpascal", but that would still require ifdefs).
2) because of all the troubles we had on i386 with a different default calling convention than the one used by code generated by other compilers (because of Delphi compatibility), we decided that on other platforms we would stick as close as possible to the ABI even for non-cdecl/cppdecl code. "const" is not part of the ABI (it's part of languages), so there we indeed sort of "do what we want" and what we do is different on different platforms (sometimes more closely sticking to the C "const" behaviour, sometimes a little less). Since the default calling convention is called "stdcall" on non-i386 platforms, changing the meaning of "const" for stdcall there would change this behaviour for almost all code. While we are free to do so (since "const" indeed has no defined meaning for stdcall on non-win32 platforms),
a) the change you propose would result in slowdowns on several platforms
b) like with any such change, it will also break some people's assembler code. We can do that, but we should try to minimise that and in combination with a), I don't think it's worth it in this case


Jonas