[fpc-devel]I suggest a new FPC feature

[Pavel V. Ozerski]

Hello,
I'm glad that you find something interesting in my reports.
Now I must answer.

1) to Peter:
>Delphi always saves ebx,esi,edi and therefor doesn't need to insert extra pushes. FPC uses
>all available registers and for stdcall it has to insert the pushes to save the original
>value.

I wrote a small test unit:

unit dtest2;
interface
procedure TestProc(x1,x2:longint);stdcall;
implementation
procedure TestProc(x1,x2:longint);stdcall;
 begin
  asm
   nop
  end;
 end;
begin
end.

Firstly I compiled it with Delphi 3.0 (dcc -J -$O- dtest), then disassembled OBJ-file with Watcom disassembler
(wdisasm -au -p dtest.OBJ). Here is procedure TestProc assembler code:

TestProc:       pushl   %ebp
                movl    %esp,%ebp
                nop
                popl    %ebp
                ret     $0x0008

I see no saving ebx,esi,edi here. Btw, this obj file could be linked not only to Delphi or CPPBuilder projects.

The same code I get if I cut out 'stdcall' keywords form dtest2 source and compile it with FPC 1.1:
_DTEST2$$_TESTPROC$LONGINT$LONGINT:
	pushl	%ebp
	movl	%esp,%ebp
	nop
	leave
	ret	$8

But if I restore  'stdcall'  keywords and compile unit with FPC 1.1, saving registers will be added:
_DTEST2$$_TESTPROC$LONGINT$LONGINT:
	pushl	%ebp
	movl	%esp,%ebp
	pushl	%edi
	pushl	%esi
	pushl	%ebx
	nop
	popl	%ebx
	popl	%esi
	popl	%edi
	leave
	ret	$8

My yesterday's tests demonstrated that also for export procedures Delphi 3.0 does not include saving registers into code.
Additionally, these tests demonstrate that default conventions which uses FPC are not the same as wich uses FPC for
procedures wich have 'stdcall' keyword.

2) To Michael:
>> 1) Is my $calling patch interesting for you?
>
>I'm not yet convinced of it's usefullness. Do not forget that we're trying to be cross-platform,
>which means that we should keep in mind conventions on other OS-es, such as Unix.

Nothing prohibits to support very different calling conventions in this compiler directive. It is more universal than syntax
used in Virtual Pascal ({$stdcall ... etc ). That is easy to make support in this $calling directive all calling conventions
supported in FPC, including future extensions. On the other hand, this directive could help to solve some programming
problems (e.g, porting code written for Delphi). Upon my honour, I did not forget not only about Unix but even about PalmOS!

>Constructors are special calls, and should NOT be declared as stdcall.
>The compiler should give an error on this.

But first, compiler does not find error here, second, PASCAL- and POPSTACK- declared constructors seem to be not buggy
(therefore I see no reason to prohibit them), third, that is easy to make ignoring $calling directive for constructors
(I know the way already now).

>> 3) Inheritance of cdecl methods is also buggy.
>
>This should be checked.
This is checked yesterday!

type
t1=class
 procedure test;cdecl;virtual;
end;
t2=class(t1)
 procedure test;cdecl;override;
end;
procedure t1.test;cdecl;
 begin
 end;
procedure t2.test;cdecl;
 begin
 end;
begin
end.
(test3.pp(10,2) Error: Asm: Duplicate label _test)

>I don't know any specification which says what registers should be saved for stdcall.
>So unless there is an official specification, the fpc way of doing may be just as
>well as any other...
I think, current "Evident stdcall" in fpc should be renamed.

To Jonas:

>Actually, stdcall is *the* standard calling convention for the 80x86
>architecture, no matter under which OS you run. It defines ebx esi and
>edi as non-volatile (ie if the callee modifies them, it has to save them
>first) and eax, ecx and edx as non-volatile (if the caller wants to use
>their current values after it called the subroutine, it should save them
>first).

Then why Delphi does not save registers in stdcall procedures?
I'm sure, it is not optimization issue : I added built-in-assember instruction mov edi,eax into body
of stdcall procedure but Delphi 3 also did not save edi!
Also if  stdcall must save these registers then default calling conventions in fpc are not true stdcall
and they should have a name.

>I agree here, unless it's possible that constructors are exported from
>libraries, otherwise it will never be possible to use objects/classes
>defined in FPC programs from Delphi ones.

Redeclaring of constructors calling conventions should be useful for CPPclasses, I think.
I hope also that CPPclasses will be usable not only with gcc but also at least with open Watcom and free Borland C++.

Sincerely, Pavel