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:56, Konstantin Münning wrote:
> 
>> 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.
> 
> A programmer actually must always be aware of how the parameters are
> passed, because otherwise in case of register parameters he can
> unknowingly overwrite some parameters while "loading" others into
> registers. So he almost always needs different code anyway.

You are right, he should be aware of but when looking at the same code
he shouldn't need to know the moon phase to be able to understand what
it's doing today ;-).

>> 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;
> 
> Well, it does depend on it and it will probably not be changed, since
> that would break too much compatibility.

So there are really people using things like the first example for
indirect addressing instead of mov eax,[eax] as they are aware of
register usage? I'm sorry but I can't imagine some real use in this
alternating behavior so it's required it to be kept and not interpreted
"correctly" by the compiler.

As I don't have Delphi, can somebody check/confirm it is done this way
there? Sorry that I'm not an easy believer ;-).

OK, here the next coding example which is broken since 1.0.10:

PROGRAM Test;
{$ASMMODE Intel}
{$R+}
 TYPE
  TTest=RECORD
         a,b,c:Word;
        END;

 PROCEDURE Test1(t:TTest);ASSEMBLER;
  ASM
   mov ax,[t.a]
  END;

BEGIN
END.

Which causes

test.pas(11,15) Error: Size suffix and destination or source size do not
match

Apparently the size check is done on t and not on t.a. It does not
matter which register I use (eax, ax or al) nor the type of a,b,c. The
code generated calculates correctly the record element size(s) so it
seems to be only the check which is flawed. This error happens when the
total size of TType is bigger than 4 bytes and range check is on.
Without range check instead of an error a warning is displayed. I must
admit that in 1.0.10 no check whatsoever was done there so this is
somehow better ;-).

Konstantin