1. Tech-Vector-Ext
  2. Topics

Operand order for widening integermultiply-accumulate instructions

Peter Ashenden
 

Hi all,

 

I’m looking at sections 11.10, 11.12, and 11.14 in the V extension spec, version 1.0. The order of operands vs1/rs1 and vs2 appears to be reversed in the assembler for the multiply-add instructions from other instructions. Is that intended?

 

In particular, the signedness of these operands is inconsistent within the V-ext instructions and with the M-ext instructions:

 

  • vwmulsu and vmulhsu: vs2 is signed, vs1/rs1 is unsigned
  • vwmaccsu: vs1/rs1 is signed, vs2 is unsigned
  • M-extension mulhsu: rs1 is signed. rs2 is unsigned

 

I understand the spec is now ratified, so any change is probably out of the question. But it would be good to know if this is what was intended and if existing implementations and tools conform to the spec as is. The reason for my question is that I’m working on a V-ext implementation and want to make sure I get it right! Thanks.

 

Cheers,

 

PA
Krste Asanovic
 

This was intentional, though the rationale seems to have dropped out
of text.

The goal was to simplify reading of assembly code, where product
inputs were kept together at beginning of instruction for all
variants:

if kept same order would have:

vfmacc.vv vd, vs2, vs1, vm # vd[i] = +(vs1[i] * vs2[i]) + vd[i]
vfmadd.vv vd, vs2, vs1, vm # vd[i] = +(vs1[i] * vd[i]) + vs2[i]

where in first case, product inputs are next to each other, while in
second case, first and third vector arguments are multiplied
together.

Krste


On Wed, 15 Mar 2023 23:48:04 +0000, "Peter Ashenden" <peter.ashenden@...> said:
| Hi all,
| I’m looking at sections 11.10, 11.12, and 11.14 in the V extension spec, version 1.0. The order of operands vs1/rs1 and vs2 appears to be reversed in the assembler for the
| multiply-add instructions from other instructions. Is that intended?

| In particular, the signedness of these operands is inconsistent within the V-ext instructions and with the M-ext instructions:

| ● vwmulsu and vmulhsu: vs2 is signed, vs1/rs1 is unsigned
| ● vwmaccsu: vs1/rs1 is signed, vs2 is unsigned
| ● M-extension mulhsu: rs1 is signed. rs2 is unsigned

| I understand the spec is now ratified, so any change is probably out of the question. But it would be good to know if this is what was intended and if existing implementations and
| tools conform to the spec as is. The reason for my question is that I’m working on a V-ext implementation and want to make sure I get it right! Thanks.

| Cheers,

| PA

|
Nick Knight
 


On Wed, Mar 15, 2023 at 8:44 PM Krste Asanovic <krste@...> wrote:

This was intentional, though the rationale seems to have dropped out
of text.

The goal was to simplify reading of assembly code, where product
inputs were kept together at beginning of instruction for all
variants:

if kept same order would have:

vfmacc.vv vd, vs2, vs1, vm   # vd[i] = +(vs1[i] * vs2[i]) + vd[i]
vfmadd.vv vd, vs2, vs1, vm   # vd[i] = +(vs1[i] * vd[i]) + vs2[i]

where in first case, product inputs are next to each other, while in
second case, first and third vector arguments are multiplied
together.

Krste


>>>>> On Wed, 15 Mar 2023 23:48:04 +0000, "Peter Ashenden" <peter.ashenden@...> said:

| Hi all,
| I’m looking at sections 11.10, 11.12, and 11.14 in the V extension spec, version 1.0. The order of operands vs1/rs1 and vs2 appears to be reversed in the assembler for the
| multiply-add instructions from other instructions. Is that intended?

| In particular, the signedness of these operands is inconsistent within the V-ext instructions and with the M-ext instructions:

|   ● vwmulsu and vmulhsu: vs2 is signed, vs1/rs1 is unsigned
|   ● vwmaccsu: vs1/rs1 is signed, vs2 is unsigned
|   ● M-extension mulhsu: rs1 is signed. rs2 is unsigned

| I understand the spec is now ratified, so any change is probably out of the question. But it would be good to know if this is what was intended and if existing implementations and
| tools conform to the spec as is. The reason for my question is that I’m working on a V-ext implementation and want to make sure I get it right! Thanks.

| Cheers,

| PA

|





Krste Asanovic
 

Thanks for reminder, Nick,

Krste

On Mar 15, 2023, at 9:35 PM, Nick Knight <nick.knight@...> wrote:


On Wed, Mar 15, 2023 at 8:44 PM Krste Asanovic <krste@...> wrote:

This was intentional, though the rationale seems to have dropped out
of text.

The goal was to simplify reading of assembly code, where product
inputs were kept together at beginning of instruction for all
variants:

if kept same order would have:

vfmacc.vv vd, vs2, vs1, vm   # vd[i] = +(vs1[i] * vs2[i]) + vd[i]
vfmadd.vv vd, vs2, vs1, vm   # vd[i] = +(vs1[i] * vd[i]) + vs2[i]

where in first case, product inputs are next to each other, while in
second case, first and third vector arguments are multiplied
together.

Krste


>>>>> On Wed, 15 Mar 2023 23:48:04 +0000, "Peter Ashenden" <peter.ashenden@...> said:

| Hi all,
| I’m looking at sections 11.10, 11.12, and 11.14 in the V extension spec, version 1.0. The order of operands vs1/rs1 and vs2 appears to be reversed in the assembler for the
| multiply-add instructions from other instructions. Is that intended?

| In particular, the signedness of these operands is inconsistent within the V-ext instructions and with the M-ext instructions:

|   ● vwmulsu and vmulhsu: vs2 is signed, vs1/rs1 is unsigned
|   ● vwmaccsu: vs1/rs1 is signed, vs2 is unsigned
|   ● M-extension mulhsu: rs1 is signed. rs2 is unsigned

| I understand the spec is now ratified, so any change is probably out of the question. But it would be good to know if this is what was intended and if existing implementations and
| tools conform to the spec as is. The reason for my question is that I’m working on a V-ext implementation and want to make sure I get it right! Thanks.

| Cheers,

| PA

|






Peter Ashenden
 

Ah, I had a dim recollection of seeing mention of this, but overlooked it when asking my question. Thanks for the reminder. All good now.

 

Cheers,

 

PA

 

From: Krste Asanovic <krste@...>
Sent: Thursday, 16 March 2023 17:18
To: Nick Knight <nick.knight@...>
Cc: Peter Ashenden <peter.ashenden@...>; tech-vector-ext@...
Subject: Re: [RISC-V] [tech-vector-ext] Operand order for widening integermultiply-accumulate instructions

 

Thanks for reminder, Nick,

 

Krste



On Mar 15, 2023, at 9:35 PM, Nick Knight <nick.knight@...> wrote:

 

 

On Wed, Mar 15, 2023 at 8:44 PM Krste Asanovic <krste@...> wrote:


This was intentional, though the rationale seems to have dropped out
of text.

The goal was to simplify reading of assembly code, where product
inputs were kept together at beginning of instruction for all
variants:

if kept same order would have:

vfmacc.vv vd, vs2, vs1, vm   # vd[i] = +(vs1[i] * vs2[i]) + vd[i]
vfmadd.vv vd, vs2, vs1, vm   # vd[i] = +(vs1[i] * vd[i]) + vs2[i]

where in first case, product inputs are next to each other, while in
second case, first and third vector arguments are multiplied
together.

Krste


>>>>> On Wed, 15 Mar 2023 23:48:04 +0000, "Peter Ashenden" <peter.ashenden@...> said:

| Hi all,
| I’m looking at sections 11.10, 11.12, and 11.14 in the V extension spec, version 1.0. The order of operands vs1/rs1 and vs2 appears to be reversed in the assembler for the
| multiply-add instructions from other instructions. Is that intended?

| In particular, the signedness of these operands is inconsistent within the V-ext instructions and with the M-ext instructions:

|   ● vwmulsu and vmulhsu: vs2 is signed, vs1/rs1 is unsigned
|   ● vwmaccsu: vs1/rs1 is signed, vs2 is unsigned
|   ● M-extension mulhsu: rs1 is signed. rs2 is unsigned

| I understand the spec is now ratified, so any change is probably out of the question. But it would be good to know if this is what was intended and if existing implementations and
| tools conform to the spec as is. The reason for my question is that I’m working on a V-ext implementation and want to make sure I get it right! Thanks.

| Cheers,

| PA

|




 

1 - 5 of 5