Hi,
I started testing the AVX512 branch:
https://svn.freepascal.org/svn/fpc/branches/tg74/avx512/

This is the code:

{$ASMMODE intel}
asm
    vaddps  zmm1, zmm2, zmm3
end;

The error message is: invalid combination of opcode and operands.

The assembly code looks correct to me:
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=22E1CA82C5506AA7E639CACEB96C72AB?doi=10.1.1.697.2949&rep=rep1&type=pdf

(look at page 19 above).

I'm I doing something very wrong? Should I submit a bug report?

Kind regards,
JP.

No, this is feature branch and work in progress. It is only useful to check out if you want to contribute to it.

Should I submit a bug report?

Only if you submit a patch with it :)

The file you want is compiler/x86/x86ins.dat, which contains the syntax information for all of the x86-64 assembler commands. A tool that's run by "make" will then generate a number of .inc files that are then referenced by the source code.
Gareth aka. Kit

On Sun 17/06/18 20:59 , Joao Schuler sent:
I can give a try to support vaddps and other instructions I need the most in AVX512. Where is the code (what file) for the above please? On Sun, Jun 17, 2018 at 6:30 PM, Florian Klämpfl wrote: Am 17.06.2018 um 06:37 schrieb Joao Schuler:
Hi,
I started testing the AVX512 branch:
https://svn.freepascal.org/svn/fpc/branches/tg74/avx512/ [2]

This is the code:

 {$ASMMODE intel}
 asm
      vaddps  zmm1, zmm2, zmm3
 end;

The error message is: invalid combination of opcode and operands.

The assembly code looks correct to me:
Should I submit a bug report?

Only if you submit a patch with it :)

I can give a try to support vaddps and other instructions I need the most in AVX512. Where is the code (what file) for the above please?

Thank you Kit.

[VADDPS]
(Ch_Wop3, Ch_Rop2, Ch_Rop1)
xmmreg,xmmreg,xmmrm \362\370\1\x58\75\120 AVX,SANDYBRIDGE
ymmreg,ymmreg,ymmrm \362\364\370\1\x58\75\120 AVX,SANDYBRIDGE

In regards to the opcode, what is the base (doesn't look hexa) for these numbers? Example:

\362\364\370\ - are these 16 bits numbers (too big for bytes)?

x58 - is this 58 hexa?

As an example,

*vaddps ymm0 ymm1 ymm3*
I was expecting:

*C5F458C3*

On Mon, Jun 18, 2018 at 5:26 AM, J. Gareth Moreton <

The x I can't remember off-hand, but I
think is a placeholder for variable input.
You might have to experiment with viewing
the disassembly of a function such as MOV
or ADD, or look at the source code of the
utility that creates the inc files. As for
the numbers, they are octal (historical
reasons, I think mostly because there were
only 8 general-purpose registers to deal
with).

The only time I personally modified this
file was some time go to reorder the MOV
commands in an attempt to get the
assembler to use a shorter byte sequence
for small negative numbers being stored in
64-bit locations.

Gareth aka. Kit

On Sun 17/06/18 22:35 , Joao Schuler
sent:

Thank you Kit. [VADDPS](Ch_Wop3, Ch_Rop2,

Ch_Rop1)xmmreg,xmmreg,xmmrm             

    3623701x5875120                AVX,SANDYBRIDGEymmreg,ymmreg,ymmrm     

3623643701x5875120           

AVX,SANDYBRIDGE

In regards to the opcode, what is the

base (doesn't look hexa) for these

numbers? Example: 362364370  - are these 16 bits numbers

(too big for bytes)?

Gareth Moreton wrote

The file you want is

compiler/x86/x86ins.dat, which contains
the syntax

information for all of the x86-64

assembler commands.

A tool that's run by "make" will then

generate a number of .inc files that

are then referenced by the source code. Gareth aka. Kit On Sun 17/06/18 20:59 , Joao Schuler

sent:

I can give a try to support vaddps and

other instructions I need the most

in AVX512. Where is the code (what file)

for the above please?

On Sun, Jun 17, 2018 at 6:30 PM, Florian

Klämpfl wrote

Am 17.06.2018 um 06:37 schrieb Joao

Schuler:

Hi, I started testing the AVX512 branch:

https://svn.freepascal.org/svn/fpc/branche
s/tg74/avx512/ [1]

combination of opcode and operands.

Ah, I forgot to actually explain what the numbers are.  They encode the machine code representation of the instruction, but it's not a direct one-to-one correlation, as they also encode parameter counts and formatting. I'm not sure where there's good narrative documentation on what it all means.  Come to think of it, I'm not entirely sure if Free Pascal knows how to handle the EVEX prefix yet.
Gareth

Hi,

I have check in the AVX512-Support in my private branch. Feel your free for testing.

https://svn.freepascal.org/svn/fpc/branches/tg74/avx512/

THANK YOU SOOOO MUCH!!! Intend to test along weekend.

Hello,
Almost everything I tested works perfectly.

This is what I tested so far:

zmm registers are properly recognized:
end [
'RAX', 'RCX', 'RDX',
'ymm2', 'ymm3', 'ymm4', 'ymm5', 'ymm0'

    {$IFDEF AVX512},'zmm2', 'zmm3', 'zmm0'{$ENDIF}
  ];

*These commands work:*

VBROADCASTSS zmm0, [rdx]
vmulps zmm2, zmm0, [rax]
vmulps zmm3, zmm0, [rax+64]
vmulps zmm2, zmm5, [rdx]
vmulps zmm3, zmm5, [rdx+64]
vmovups [rax], zmm2
vmovups [rax+64], zmm3
vaddps zmm2, zmm2, [rdx]
vaddps zmm3, zmm3, [rdx+64]
vsubps zmm2, zmm2, [rdx]
vsubps zmm3, zmm3, [rdx+64]

I'm getting more "inline" warnings than usual. Unfortunately, source forge is offline now and I can't share the code.

Question: should the following 2 commands be supported?

- vfmadd231ps zmm0, zmm5, [rax]
- VEXTRACTF128 xmm3, zmm0, 2

Congrats for the work,
JP

Quick update in reply to my own question: VEXTRACTF128 should not support zmm registers. Therefore, the current behavior is correct. This is the reference:
https://www.felixcloutier.com/x86/VEXTRACTF128:VEXTRACTF32x4:VEXTRACTF64x2:VEXTRACTF32x8:VEXTRACTF64x4.html

Anyway, supporting VEXTRACTF32x4 would help me.

Hi,

I have checkin vextracti.., vextractf..  avx512-instructions.

I can confirm that this works:

VEXTRACTF32x4 xmm2, zmm0, 1
VEXTRACTF32x4 xmm3, zmm0, 2
VEXTRACTF32x4 xmm4, zmm0, 3

Well done job!

I have more good news: I've just finished coding support for AVX512 in my own project: https://www.youtube.com/watch?v=qGnfwpKUTIQ

I'm getting loads of warnings "marked as inline is not inlined". Is there anything I can do to be able to properly compile with inlines? I can't tell users to use your branch as of now as the lack of inline decreases speed.

Anyway, thank you!

The avx512 branch shouldn't be different in this regard?