Probably a known bug

[LemonParty]

FPC version 3.2.2. Just inspect an output of the next program:

Code: Pascal  [Select][+][-]

1. {$mode objfpc}{$H+}
2. {$ASMMODE intel}
3. {$Calling Register}
4.  
5. var
6.         A: array[0..1]of Word;
7.        
8. procedure Pr(var Buf: Word);assembler;
9. asm
10.         mov ecx,$000F000F
11.         mov [Buf],cx
12. end;
13.  
14. begin
15.         Pr(A[0]);
16.         Writeln(A[0], ' ', A[1]);
17. end.
18.  

Is this a bug? If so is it fixed?

[marcov]

It may be a bug worth reporting. Seem the intention that you want a 16-bit move (by specifying cx) isn't picked up 100%.

This is easily worked around though by explicitly indicating you want to by using

Code: Pascal  [Select][+][-]

1.             mov word ptr [Buf],cx
2.  

[440bx]

Code: ASM  [Select][+][-]

1. H:\Dev\Tests\00_WordArray\WordArray.lpr:13  asm
2. 00000001000015D0 55                       push rbp
3. 00000001000015D1 4889E5                   mov rbp,rsp
4. H:\Dev\Tests\00_WordArray\WordArray.lpr:14  mov ecx,$000F000F
5. 00000001000015D4 B90F000F00               mov ecx,$000F000F
6. H:\Dev\Tests\00_WordArray\WordArray.lpr:15  mov [Buf],cx
7. 00000001000015D9 488909                   mov [rcx],rcx
8. H:\Dev\Tests\00_WordArray\WordArray.lpr:16  end;
9. 00000001000015DC 488D6500                 lea rsp,[rbp+$00]
10. 00000001000015E0 5D                       pop rbp
11. 00000001000015E1 C3                       ret
12.  

Yes, definitely a bug because it is moving rcx instead of cx.

However, another thing that should be mentioned is that depending on the ABI that code will not work anyway because in 64 bit the first parameter is often passed in rcx which is being overwritten with a constant value resulting in an invalid pointer.

Also, strictly speaking the "word ptr" should not really make a difference in this case because the size of the move is determined by the source operand, cx in this case.

Conclusion: yes, there is a bug but, that code is asking for trouble anyway.

[ASerge]

However, another thing that should be mentioned is that depending on the ABI that code will not work anyway because in 64 bit the first parameter is often passed in rcx which is being overwritten with a constant value resulting in an invalid pointer.

By the way, 64-bit FPC 3.2.2 will not compile this code: project1.lpr(10,24) Error: Size suffix and destination or source size do not match

[BrunoK]

Looks that A[0] address is passed in ECX, thus, in the procedure pr the address of buf is changed by

Code: Pascal  [Select][+][-]

1.            MOV     ECX,$000F000F

Calling code for pr in main proogram is
C:\Users\BRUNOK~1\AppData\Local\Temp\project1.lpr:19 

Code: Pascal  [Select][+][-]

1. Pr(A[0]);
2. 0000000100001600 488D0D092A0100           lea rcx,[rip+$00012A09]    # $0000000100014010
3. 0000000100001607 E8B4FFFFFF               call -$0000004C    # $00000001000015C0 Pr project1.lpr:11
4. C:\Users\BRUNOK~1\AppData\Local\Temp\project1.lpr:20  Writeln(A[0], ' ', A[1]);
5. 000000010000160C E8BF740000               call +$000074BF    # $0000000100008AD0 fpc_get_output text.inc:658
6. 0000000100001611 4889C3                   mov rbx,rax

Replace ECX by EAX in pr and there is no error.

[440bx]

By the way, 64-bit FPC 3.2.2 will not compile this code: project1.lpr(10,24) Error: Size suffix and destination or source size do not match

You probably have your settings different than mine. 

With my settings v3.2.2 compiles that code with a _warning_ not an error.

Replace ECX by EAX in pr and there is no error.

There is no error but, the code is still wrong.

Code: ASM  [Select][+][-]

1. H:\Dev\Tests\00_WordArray\WordArray.lpr:13  asm
2. 00000001000015D0 55                       push rbp
3. 00000001000015D1 4889E5                   mov rbp,rsp
4. H:\Dev\Tests\00_WordArray\WordArray.lpr:14  mov eax,$000F000F
5. 00000001000015D4 B80F000F00               mov eax,$000F000F
6. H:\Dev\Tests\00_WordArray\WordArray.lpr:15  mov [Buf], ax
7. 00000001000015D9 488901                   mov [rcx],rax
8. H:\Dev\Tests\00_WordArray\WordArray.lpr:16  end;
9. 00000001000015DC 488D6500                 lea rsp,[rbp+$00]
10. 00000001000015E0 5D                       pop rbp
11. 00000001000015E1 C3                       ret
12.  

The code is moving rax instead of ax thus overwriting the dword that follows the array "A".

In a way the absence of an error made matters worse because there is no indication that a dword has been overwritten with junk.

[BrunoK]

Code: Pascal  [Select][+][-]

1.   procedure Pr(var Buf: word); assembler;
2.   asm
3.            MOV     EAX,$000F000F
4.            MOV WORD PTR[Buf],AX
5.   end;
6.  

[440bx]

Code: Pascal  [Select][+][-]

1.   procedure Pr(var Buf: word); assembler;
2.   asm
3.            MOV     EAX,$000F000F
4.            MOV WORD PTR[Buf],AX
5.   end;
6.  

Yes, the "word ptr" in this case is rather important.

[LemonParty]

Seems I found 1 similar bug.

Code: Pascal  [Select][+][-]

1. procedure Pr1(W: Word);assembler;
2. asm
3.         imul ecx,cx
4. end;
5.  

This code compiles with no error. Imul arguments should be the same size.

[ASerge]

With my settings v3.2.2 compiles that code with a _warning_ not an error.

You're right, I have these options by default: -al -Oodfa
With them, the last example @LemonParty gets an error: (39,0) Error: linker: Error: operand type mismatch for `imul'

[Thaddy]

Since you use -al that means always external linker?
Then that also means that the internal linker does not catch the operant size mismatch, or at least does not err, but warns. That seems a bug too.

[PascalDragon]

Since you use -al that means always external linker?
Then that also means that the internal linker does not catch the operant size mismatch, or at least does not err, but warns. That seems a bug too.

-al is external assembler, not linker (or more precisely source writing assembler, but since none of the internal assemblers support this it's essentially always an external assembler). External linker is -Xe.