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

[Konstantin Münning]

Jonas Maebe wrote:
> 
> On 18 aug 2006, at 13:36, Konstantin Münning wrote:
> 
>> PROGRAM Original;
>> {$ASMMODE Intel}
>>  PROCEDURE Test(p:Pointer;l:LongInt;w:Word;b:Byte);ASSEMBLER;
>>   ASM
>>    mov eax,[p]
>>    mov eax,[l]
>>    mov ax,[w]
>>    mov al,[b]
>>   END;
>> BEGIN
>> END.
>>
>> This program is like the code I'm using which works with fpc 1.0.10 and
>> BP (BP is 16 bit only so without eax). FPC 2.0.x complains on the mov
>> ax,[w] with the error(s):
>>
>> original.pas(7,13) Error: Asm: 16 Bit references not supported
>> original.pas(7,13) Error: Asm: Invalid effective address
> 
> 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

> Add {$calling stdcall} (or alternatively {$calling oldfpccall}, but
> that's not encouraged since this calling convention is FPC-specific) to
> you source to switch back to passing all parameters on the stack.

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

Konstantin