Pavel V. Ozerski wroteHello Peter and all FPC team,
Did you look at my $calling patch?
I think the problem is that both Peter and Florian are at this time very busy, and have not yet had the opportunity to look at it.
Show quoted text 23 lines
Maybe, I should fix or improve something in it? Or you needs some my
commentaries?
Btw, I'm not sure that general parsing of procedure directives in FPC
is good. There are exist also some differences between FPC and Delphi.
This example can be compiled with Delphi 3 but not with FPC:
{$ifdef fpc}
{$mode delphi}
{$endif}
procedure X(x1,x2:longint);stdcall;cdecl;pascal;
begin
end;
begin
X(1,2);
end.
FPC 1.1 gives an error message:
test.pp(4,42) Error: Procedure directive "PASCAL" has conflicts with other directives
test.pp(4,42) Fatal: Syntax error, "BEGIN" expected but "identifier PASCAL" found
Delphi 3 compiles this sample successfully, I assume that last calling
convention directive overlaps all previous.
But it is an error nevertheless, you should specify only 1 calling convention. It's just an error in Delphi; Look in the help:
"When you declare a procedure or function, you can specify a calling convention using one of the directives register, pascal, cdecl, stdcall, and safecall. For example,"
it says clearly: using one !
I think, Delphi behavior must at least be supported in $delphi mode of
FPC.
I don't agree, I think it is an error in the Delphi parser.
Show quoted text 19 lines
Additionally, I think, procedure directives must be sorted into
groups to simplify and improve solving conflicts and overlapping.
I suggest:
1) introduce new type tProcDirKind=(pdk_Mangling, pdk_CallConv... etc;
2) add to proc_dir_rec type (unit pdecsub.pas) a new field, kind:
tProcDirKind;
3) differently check conflicts between directives for every kind;
4) separate handling of calling conventions from handling of name
mangling. This solution can seem to be painful, because can disturb
compatibility with older FPC versions, but I think, it is necessary.
New keywords like "cmangled", "cppmangled" etc must be introduced,
default using of calling conventions-related directives must cause no
changes in names mangling. Btw, relationships between name mangling and
calling conventions is not only strange but also somewhere wrong now. For
example, function TheFunc(x1:pchar;x2:longint):longint;stdcall;
now will be mangled in FPC to _THEFUNC$PCHAR$LONGINT but C/C++
compilers will mangle this stdcall function to .
That's not logical, to emulate C/C++ name mangling only for a part of common
calling conventions!
Nevertheless, If I remember correctly, the Delphi/Kylix compiler does the same as FPC in this area. On linux, 'cdecl' also mangles the name.
Show quoted text 37 lines
Another problem which is caused with the unasked name mangling
changes: A small demo which includes 2 units and one program which
used these units:
unit unit1;
interface
procedure test(x:longint);cdecl;
implementation
procedure test(x:longint);cdecl;
begin
writeln('1:',x);
end;
end.
unit unit2;
interface
procedure test(x:longint);cdecl;
implementation
procedure test(x:longint);cdecl;
begin
writeln('2:',x);
end;
end.
program main;
uses
unit1,unit2;
begin
unit1.test(100);
unit2.test(100);
end.
Try to build this project without changes in sources!
I got problems at linking stage because both cdecl procedures in
different units have the same mangled name! This example demonstrates
that non-FPC name mangling must be used very carefully, but now it is
applying in very common cases.
But it is clearly stated in the documentation that this will happen, so you have been warned.
Show quoted text 11 lines
Btw, IMHO, even if the "automatic"
C-like name mangling would be excluded from FPC, the compiler became
not very less flexible because there are exist also syntax constructions
like
procedure TheProc(x1:pchar);stdcall;external name '';
for import and
procedure TheProc(x1:pchar);stdcall;[public,alias:''];
for export.
I could also try to solve some these problems but I could know the
lot of my $calling patch, because solving ways depend on it.
I am not sure which course should be followed; I am inclined to leave it as it is; As long as every effect of the directives is clearly documented, I do not see any reason to change it.
What would be a good thing is to split the implementation in the compiler into a name-mangling part and calling convention part, as you suggest, se specifying a directive sets 2 variables: One specifycing the name mangling, and one specifying the calling convention. It will definitely improve the compiler's internal workings.
But you should try and wait for an answer of Peter or Florian, as they are mostly the experts in this area.
Michael.
