Assembler (Intel) inconsistencies in 2.0.x, Was: Re: [fpc-devel] Bug: compilation loop in 2.0.2 when using -So

Jonas Maebe jonas.maebe at
Fri Aug 18 14:20:23 CEST 2006

On 18 aug 2006, at 14:10, Konstantin M√ľnning wrote:

>> That's because the default calling convention is now register  
>> instead of
>> oldfpccall. p is now passed in eax, l in edx and w in cx. So the the
>> compiling is complaining because the above now means "mov ax, [cx]".
> Does this mean above code is translated to
>    mov eax,[eax]
>    mov eax,[ebx]
>    mov ax,[cx]
> ?


> Because that would be awfully wrong! With the new calling convention
> it should be translated as
>    mov eax,eax
>    mov eax,ebx
>    mov ax,cx

I presume that what we do is Delphi compatible. To, it seems more  
like the TP/Delphi (and probably masm/tasm) behaviour of treating  
"[p]" and "p" as the same thing was wrong. [] means a memory  
reference and [p] should actually mean something like [[ebp+8]] or so  
if p is stored at address ebp+8 (which is an addressing mode that is  
not supported by the 80x86, but it is supported by e.g. the m68k).

> Is the $calling mixable? I mean would units compiled with {$calling
> stdcall} work with programs compiled without or with some other  
> $calling?

The calling convention of routine is saved in the ppu file of a  
compiled unit, so if it's called from another module (program or  
unit) the approrpriate calling convention will be looked up and used.

You can also specify the calling convention of an individual  
procedure by adding it after it, e.g.

procedure test; stdcall;


More information about the fpc-devel mailing list