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 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]
>>
>> ?
> 
> Yes.
> 
>> 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).

As I'm not using Delphi I can't tell, but it is in fact the improval of
TASM ideal mode over the MASM quirks. Yes, [] means a memory reference
which is correct on first sight. All assembler labels are nothing than
pointers to memory. So using move ax,[p] would mean something like mov
ax,[ebp+8] which is correct whrereas mov ax,p would mean mov ax,ebp+8 or
for x86 lea ax,ebp+8. I am using IDEAL TASM syntax in TASM and BP and it
makes the code quite clear IMHO.

So a programmer should not need exactly to know if/when a variable is
cached in a register or saved on the stack (=memory) and when
referencing it the same way the same result should be expected.

Here an example where the same source code is compiled differently which
should not depend on calling convention, register caching or whatsoever:

PROCEDURE Test(l:LongInt);ASSEMBLER;
 ASM
  mov eax,[l]
 END;

PROCEDURE Test;ASSEMBLER;
 VAR l:LongInt;
 ASM
  mov eax,[l]
 END;

Konstantin