[fpc-devel] constref in Windows

[Jonas Maebe]

On 20 Nov 2010, at 16:43, Paul Ishenin wrote:

> 20.11.2010 18:52, Jonas Maebe wrote:
>> 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
> don't use const and it will be passed by value -> no slowdown

Lots of existing Pascal code uses "const", and generally "const" is used to give a hint to the compiler so it can make code faster.

>> 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
> why assembler outweights interfaces?

It's not only assembler, it's assembler + the fact that the generated code for const parameters will become worse on most platforms.

> Moreover those who need to port their projects to FPC will need to review their assember anyway because as I know assember is not compatible.

It's not about porting code, it's about existing FPC code.


Jonas