V extension groups analogue to the standard groups


tobias.strauch@...
 

Apologies if this is old stuff already dismissed. But I give it a try anyway.


Wouldn't it make sense to separate more complex vector instructions from more trivial ones? Already with the very first base release ? Vector instructions can also be helpful in small devices #IOT #Edge #GAP8 #RISCY without the need to fully support floating point instructions or without the need for a quad multiply.


The suggestion would be to basically group vector extensions analogue to the standard instructions (I, M, F, D, Q, …), instead of having an already complex base and then subtract or re-define subsets of instructions again ?


Wouldn't that be in-line with the RISC-V philosophy of modularity and simplicity ? The beauty would be that you have a non-vector and a vector group version.


Possible nomenclature based on order:


M: Standard Multiply Divide Instructions (MUL, ...)

V: Very Basic Vector Instructions (VSETVL, ...)

MV: Standard Multiply Divide Instructions and Very Basic Vector Instructions (MUL, VSETVL, ...

VM: Standard Multiply Divide Instructions, Very Basic Vector Instructions and Vector Integer Multiply\Divide Instructions (MUL, VSETVL, VMUL, ...)


F, D, Q analogue to M as suggested.


The V version will not be a 1:1 match with the standard version and will cover additional aspects. But it can be argued, that when you implement the V version (of M, F, D, Q, ...), then you most likely will have the relevant standard counterparts implemented as well anyway.


Kind Regards, Tobias


Andrew Waterman
 

Quad-widening ops have been moved to a separate extension, Zvqmac.

I believe the intent is that the capital-V V extension supports the same FP datatypes as the scalar ISA, so e.g., RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.

I’m surprised all those hashtags made it past the spam filter!

On Thu, Aug 20, 2020 at 11:42 AM Strauch, Tobias (HENSOLDT Cyber GmbH) <tobias.strauch@...> wrote:

Apologies if this is old stuff already dismissed. But I give it a try anyway.


Wouldn't it make sense to separate more complex vector instructions from more trivial ones? Already with the very first base release ? Vector instructions can also be helpful in small devices #IOT #Edge #GAP8 #RISCY without the need to fully support floating point instructions or without the need for a quad multiply.


The suggestion would be to basically group vector extensions analogue to the standard instructions (I, M, F, D, Q, …), instead of having an already complex base and then subtract or re-define subsets of instructions again ?


Wouldn't that be in-line with the RISC-V philosophy of modularity and simplicity ? The beauty would be that you have a non-vector and a vector group version.


Possible nomenclature based on order:


M: Standard Multiply Divide Instructions (MUL, ...)

V: Very Basic Vector Instructions (VSETVL, ...)

MV: Standard Multiply Divide Instructions and Very Basic Vector Instructions (MUL, VSETVL, ...

VM: Standard Multiply Divide Instructions, Very Basic Vector Instructions and Vector Integer Multiply\Divide Instructions (MUL, VSETVL, VMUL, ...)


F, D, Q analogue to M as suggested.


The V version will not be a 1:1 match with the standard version and will cover additional aspects. But it can be argued, that when you implement the V version (of M, F, D, Q, ...), then you most likely will have the relevant standard counterparts implemented as well anyway.


Kind Regards, Tobias


Simon Davidmann Imperas
 

A question to clarify. You state:
      RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.  

This means if I understand you that we need to add F to get F hardware in the vector unit - so RV32IV means V with no F hardware, and RV32IFV includes F hardware.

So for consistency...

What does RV32IV means for M hardware multiply - do I need to RV32IMV to get scalar and vector hardware multiply?

RV32IV means no F and no M hardware? - so I need to explicitly include the extensions I need as V assumes nothing but I?

Or is something assumed for M?

thanks

On Thu, Aug 20, 2020 at 8:48 PM Andrew Waterman <andrew@...> wrote:
Quad-widening ops have been moved to a separate extension, Zvqmac.

I believe the intent is that the capital-V V extension supports the same FP datatypes as the scalar ISA, so e.g., RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.

I’m surprised all those hashtags made it past the spam filter!

On Thu, Aug 20, 2020 at 11:42 AM Strauch, Tobias (HENSOLDT Cyber GmbH) <tobias.strauch@...> wrote:

Apologies if this is old stuff already dismissed. But I give it a try anyway.


Wouldn't it make sense to separate more complex vector instructions from more trivial ones? Already with the very first base release ? Vector instructions can also be helpful in small devices #IOT #Edge #GAP8 #RISCY without the need to fully support floating point instructions or without the need for a quad multiply.


The suggestion would be to basically group vector extensions analogue to the standard instructions (I, M, F, D, Q, …), instead of having an already complex base and then subtract or re-define subsets of instructions again ?


Wouldn't that be in-line with the RISC-V philosophy of modularity and simplicity ? The beauty would be that you have a non-vector and a vector group version.


Possible nomenclature based on order:


M: Standard Multiply Divide Instructions (MUL, ...)

V: Very Basic Vector Instructions (VSETVL, ...)

MV: Standard Multiply Divide Instructions and Very Basic Vector Instructions (MUL, VSETVL, ...

VM: Standard Multiply Divide Instructions, Very Basic Vector Instructions and Vector Integer Multiply\Divide Instructions (MUL, VSETVL, VMUL, ...)


F, D, Q analogue to M as suggested.


The V version will not be a 1:1 match with the standard version and will cover additional aspects. But it can be argued, that when you implement the V version (of M, F, D, Q, ...), then you most likely will have the relevant standard counterparts implemented as well anyway.


Kind Regards, Tobias



--
====================================================================
The information contained in this electronic mail message and any attachments hereto
is privileged and confidential information intended only for the use of the individual or 
entity named above or their designee.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this communication in error 
please immediately notify us by return  message or by telephone and delete the 
original message from your mail system.  Thank you.
====================================================================


Andrew Waterman
 



On Fri, Aug 21, 2020 at 2:43 PM Simon Davidmann <simond@...> wrote:
A question to clarify. You state:
      RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.  

This means if I understand you that we need to add F to get F hardware in the vector unit - so RV32IV means V with no F hardware, and RV32IFV includes F hardware.

So for consistency...

What does RV32IV means for M hardware multiply - do I need to RV32IMV to get scalar and vector hardware multiply?

I don’t believe the spec explicitly addresses this question, but I agree it makes sense. Alternatively, V could require M, since it doesn’t make much sense to pay for a vector unit but be too stingy to pay for a multiplier. But that might be less consistent. (My recommendation is that RV32IV continue to mean “no multiplier”, even though it’s a silly configuration.)


RV32IV means no F and no M hardware? - so I need to explicitly include the extensions I need as V assumes nothing but I?

My recommendation is to clarify in the spec that RV32IV is a valid config with no FPU in the vector unit, and RV32IFV is also a valid config with an FPU in both scalar and vector.


Or is something assumed for M?

If we choose to define that V implies M, RV32IV and RV32IMV would be synonyms.


thanks

On Thu, Aug 20, 2020 at 8:48 PM Andrew Waterman <andrew@...> wrote:
Quad-widening ops have been moved to a separate extension, Zvqmac.

I believe the intent is that the capital-V V extension supports the same FP datatypes as the scalar ISA, so e.g., RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.

I’m surprised all those hashtags made it past the spam filter!

On Thu, Aug 20, 2020 at 11:42 AM Strauch, Tobias (HENSOLDT Cyber GmbH) <tobias.strauch@...> wrote:

Apologies if this is old stuff already dismissed. But I give it a try anyway.


Wouldn't it make sense to separate more complex vector instructions from more trivial ones? Already with the very first base release ? Vector instructions can also be helpful in small devices #IOT #Edge #GAP8 #RISCY without the need to fully support floating point instructions or without the need for a quad multiply.


The suggestion would be to basically group vector extensions analogue to the standard instructions (I, M, F, D, Q, …), instead of having an already complex base and then subtract or re-define subsets of instructions again ?


Wouldn't that be in-line with the RISC-V philosophy of modularity and simplicity ? The beauty would be that you have a non-vector and a vector group version.


Possible nomenclature based on order:


M: Standard Multiply Divide Instructions (MUL, ...)

V: Very Basic Vector Instructions (VSETVL, ...)

MV: Standard Multiply Divide Instructions and Very Basic Vector Instructions (MUL, VSETVL, ...

VM: Standard Multiply Divide Instructions, Very Basic Vector Instructions and Vector Integer Multiply\Divide Instructions (MUL, VSETVL, VMUL, ...)


F, D, Q analogue to M as suggested.


The V version will not be a 1:1 match with the standard version and will cover additional aspects. But it can be argued, that when you implement the V version (of M, F, D, Q, ...), then you most likely will have the relevant standard counterparts implemented as well anyway.


Kind Regards, Tobias



--
====================================================================
The information contained in this electronic mail message and any attachments hereto
is privileged and confidential information intended only for the use of the individual or 
entity named above or their designee.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this communication in error 
please immediately notify us by return  message or by telephone and delete the 
original message from your mail system.  Thank you.
====================================================================


Guy Lemieux
 

I think a common embedded and FPGA scenarios  will be F on the scalar side but no F on the vector side. Adding F to V is nontrivial in area, particularly for FPGAs that lack FPUs, yet an integer-only V makes a lot of sense for pixel processing etc. F in the scalar is a nice-to-have for code size and to calculate scalar parameters, eg in OpenCV and OpenVX.

The current nomenclature assumptions don’t allow this, but I think that they should do so.

Guy

On Fri, Aug 21, 2020 at 4:30 PM Andrew Waterman <andrew@...> wrote:


On Fri, Aug 21, 2020 at 2:43 PM Simon Davidmann <simond@...> wrote:
A question to clarify. You state:
      RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.  

This means if I understand you that we need to add F to get F hardware in the vector unit - so RV32IV means V with no F hardware, and RV32IFV includes F hardware.

So for consistency...

What does RV32IV means for M hardware multiply - do I need to RV32IMV to get scalar and vector hardware multiply?

I don’t believe the spec explicitly addresses this question, but I agree it makes sense. Alternatively, V could require M, since it doesn’t make much sense to pay for a vector unit but be too stingy to pay for a multiplier. But that might be less consistent. (My recommendation is that RV32IV continue to mean “no multiplier”, even though it’s a silly configuration.)


RV32IV means no F and no M hardware? - so I need to explicitly include the extensions I need as V assumes nothing but I?

My recommendation is to clarify in the spec that RV32IV is a valid config with no FPU in the vector unit, and RV32IFV is also a valid config with an FPU in both scalar and vector.


Or is something assumed for M?

If we choose to define that V implies M, RV32IV and RV32IMV would be synonyms.


thanks

On Thu, Aug 20, 2020 at 8:48 PM Andrew Waterman <andrew@...> wrote:
Quad-widening ops have been moved to a separate extension, Zvqmac.

I believe the intent is that the capital-V V extension supports the same FP datatypes as the scalar ISA, so e.g., RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.

I’m surprised all those hashtags made it past the spam filter!

On Thu, Aug 20, 2020 at 11:42 AM Strauch, Tobias (HENSOLDT Cyber GmbH) <tobias.strauch@...> wrote:
















Apologies if this is old stuff already dismissed. But I give it a try anyway.








Wouldn't it make sense to separate more complex vector instructions from more trivial ones? Already with the very first base release ? Vector instructions can also be helpful in small devices #IOT #Edge #GAP8

#RISCY without the need to fully support floating point instructions or without the need for a quad multiply.








The suggestion would be to basically group vector extensions analogue to the standard instructions (I, M, F, D, Q, …), instead of having an already complex base and then subtract or re-define subsets of instructions

again ?








Wouldn't that be in-line with the RISC-V philosophy of modularity and simplicity ? The beauty would be that you have a non-vector and a vector group version.








Possible nomenclature based on order:








M: Standard Multiply Divide Instructions (MUL, ...)



V: Very Basic Vector Instructions (VSETVL, ...)



MV: Standard Multiply Divide Instructions and Very Basic Vector Instructions (MUL, VSETVL, ...



VM: Standard Multiply Divide Instructions, Very Basic Vector Instructions and Vector Integer Multiply\Divide Instructions (MUL, VSETVL, VMUL, ...)








F, D, Q analogue to M as suggested.








The V version will not be a 1:1 match with the standard version and will cover additional aspects. But it can be argued, that when you implement the V version (of M, F, D, Q, ...), then you most likely will have

the relevant standard counterparts implemented as well anyway.








Kind Regards, Tobias



































--
====================================================================
The information contained in this electronic mail message and any attachments hereto
is privileged and confidential information intended only for the use of the individual or 
entity named above or their designee.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this communication in error 
please immediately notify us by return  message or by telephone and delete the 
original message from your mail system.  Thank you.
====================================================================











Andrew Waterman
 



On Fri, Aug 21, 2020 at 4:51 PM Guy Lemieux <glemieux@...> wrote:
I think a common embedded and FPGA scenarios  will be F on the scalar side but no F on the vector side. Adding F to V is nontrivial in area, particularly for FPGAs that lack FPUs, yet an integer-only V makes a lot of sense for pixel processing etc. F in the scalar is a nice-to-have for code size and to calculate scalar parameters, eg in OpenCV and OpenVX.

The current nomenclature assumptions don’t allow this, but I think that they should do so.

We definitely want to sanction configurations that have different datatype support on scalar and vector.  The current thinking is that the letter V means "whatever apps-profile processors want", just like what "G" means on the scalar side.  Perhaps the "vector-with-fewer-datatypes-than-scalar" case can be described as Zvbase instead of V?


Guy

On Fri, Aug 21, 2020 at 4:30 PM Andrew Waterman <andrew@...> wrote:


On Fri, Aug 21, 2020 at 2:43 PM Simon Davidmann <simond@...> wrote:
A question to clarify. You state:
      RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.  

This means if I understand you that we need to add F to get F hardware in the vector unit - so RV32IV means V with no F hardware, and RV32IFV includes F hardware.

So for consistency...

What does RV32IV means for M hardware multiply - do I need to RV32IMV to get scalar and vector hardware multiply?

I don’t believe the spec explicitly addresses this question, but I agree it makes sense. Alternatively, V could require M, since it doesn’t make much sense to pay for a vector unit but be too stingy to pay for a multiplier. But that might be less consistent. (My recommendation is that RV32IV continue to mean “no multiplier”, even though it’s a silly configuration.)


RV32IV means no F and no M hardware? - so I need to explicitly include the extensions I need as V assumes nothing but I?

My recommendation is to clarify in the spec that RV32IV is a valid config with no FPU in the vector unit, and RV32IFV is also a valid config with an FPU in both scalar and vector.


Or is something assumed for M?

If we choose to define that V implies M, RV32IV and RV32IMV would be synonyms.


thanks

On Thu, Aug 20, 2020 at 8:48 PM Andrew Waterman <andrew@...> wrote:
Quad-widening ops have been moved to a separate extension, Zvqmac.

I believe the intent is that the capital-V V extension supports the same FP datatypes as the scalar ISA, so e.g., RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.

I’m surprised all those hashtags made it past the spam filter!

On Thu, Aug 20, 2020 at 11:42 AM Strauch, Tobias (HENSOLDT Cyber GmbH) <tobias.strauch@...> wrote:
















Apologies if this is old stuff already dismissed. But I give it a try anyway.








Wouldn't it make sense to separate more complex vector instructions from more trivial ones? Already with the very first base release ? Vector instructions can also be helpful in small devices #IOT #Edge #GAP8

#RISCY without the need to fully support floating point instructions or without the need for a quad multiply.








The suggestion would be to basically group vector extensions analogue to the standard instructions (I, M, F, D, Q, …), instead of having an already complex base and then subtract or re-define subsets of instructions

again ?








Wouldn't that be in-line with the RISC-V philosophy of modularity and simplicity ? The beauty would be that you have a non-vector and a vector group version.








Possible nomenclature based on order:








M: Standard Multiply Divide Instructions (MUL, ...)



V: Very Basic Vector Instructions (VSETVL, ...)



MV: Standard Multiply Divide Instructions and Very Basic Vector Instructions (MUL, VSETVL, ...



VM: Standard Multiply Divide Instructions, Very Basic Vector Instructions and Vector Integer Multiply\Divide Instructions (MUL, VSETVL, VMUL, ...)








F, D, Q analogue to M as suggested.








The V version will not be a 1:1 match with the standard version and will cover additional aspects. But it can be argued, that when you implement the V version (of M, F, D, Q, ...), then you most likely will have

the relevant standard counterparts implemented as well anyway.








Kind Regards, Tobias



































--
====================================================================
The information contained in this electronic mail message and any attachments hereto
is privileged and confidential information intended only for the use of the individual or 
entity named above or their designee.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this communication in error 
please immediately notify us by return  message or by telephone and delete the 
original message from your mail system.  Thank you.
====================================================================











Colin Schmidt
 

We had a long discussion about how to name different portions of the vector ISA at one of the recent meetings.

You can see the issue here: https://github.com/riscv/riscv-v-spec/issues/550
And the meeting minutes here: https://github.com/riscv/riscv-v-spec/blob/master/minutes/20200807-V-minutes.txt

Thanks,
Colin

On Fri, Aug 21, 2020 at 5:49 PM Andrew Waterman <andrew@...> wrote:


On Fri, Aug 21, 2020 at 4:51 PM Guy Lemieux <glemieux@...> wrote:
I think a common embedded and FPGA scenarios  will be F on the scalar side but no F on the vector side. Adding F to V is nontrivial in area, particularly for FPGAs that lack FPUs, yet an integer-only V makes a lot of sense for pixel processing etc. F in the scalar is a nice-to-have for code size and to calculate scalar parameters, eg in OpenCV and OpenVX.

The current nomenclature assumptions don’t allow this, but I think that they should do so.

We definitely want to sanction configurations that have different datatype support on scalar and vector.  The current thinking is that the letter V means "whatever apps-profile processors want", just like what "G" means on the scalar side.  Perhaps the "vector-with-fewer-datatypes-than-scalar" case can be described as Zvbase instead of V?


Guy

On Fri, Aug 21, 2020 at 4:30 PM Andrew Waterman <andrew@...> wrote:


On Fri, Aug 21, 2020 at 2:43 PM Simon Davidmann <simond@...> wrote:
A question to clarify. You state:
      RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.  

This means if I understand you that we need to add F to get F hardware in the vector unit - so RV32IV means V with no F hardware, and RV32IFV includes F hardware.

So for consistency...

What does RV32IV means for M hardware multiply - do I need to RV32IMV to get scalar and vector hardware multiply?

I don’t believe the spec explicitly addresses this question, but I agree it makes sense. Alternatively, V could require M, since it doesn’t make much sense to pay for a vector unit but be too stingy to pay for a multiplier. But that might be less consistent. (My recommendation is that RV32IV continue to mean “no multiplier”, even though it’s a silly configuration.)


RV32IV means no F and no M hardware? - so I need to explicitly include the extensions I need as V assumes nothing but I?

My recommendation is to clarify in the spec that RV32IV is a valid config with no FPU in the vector unit, and RV32IFV is also a valid config with an FPU in both scalar and vector.


Or is something assumed for M?

If we choose to define that V implies M, RV32IV and RV32IMV would be synonyms.


thanks

On Thu, Aug 20, 2020 at 8:48 PM Andrew Waterman <andrew@...> wrote:
Quad-widening ops have been moved to a separate extension, Zvqmac.

I believe the intent is that the capital-V V extension supports the same FP datatypes as the scalar ISA, so e.g., RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.

I’m surprised all those hashtags made it past the spam filter!

On Thu, Aug 20, 2020 at 11:42 AM Strauch, Tobias (HENSOLDT Cyber GmbH) <tobias.strauch@...> wrote:
















Apologies if this is old stuff already dismissed. But I give it a try anyway.








Wouldn't it make sense to separate more complex vector instructions from more trivial ones? Already with the very first base release ? Vector instructions can also be helpful in small devices #IOT #Edge #GAP8

#RISCY without the need to fully support floating point instructions or without the need for a quad multiply.








The suggestion would be to basically group vector extensions analogue to the standard instructions (I, M, F, D, Q, …), instead of having an already complex base and then subtract or re-define subsets of instructions

again ?








Wouldn't that be in-line with the RISC-V philosophy of modularity and simplicity ? The beauty would be that you have a non-vector and a vector group version.








Possible nomenclature based on order:








M: Standard Multiply Divide Instructions (MUL, ...)



V: Very Basic Vector Instructions (VSETVL, ...)



MV: Standard Multiply Divide Instructions and Very Basic Vector Instructions (MUL, VSETVL, ...



VM: Standard Multiply Divide Instructions, Very Basic Vector Instructions and Vector Integer Multiply\Divide Instructions (MUL, VSETVL, VMUL, ...)








F, D, Q analogue to M as suggested.








The V version will not be a 1:1 match with the standard version and will cover additional aspects. But it can be argued, that when you implement the V version (of M, F, D, Q, ...), then you most likely will have

the relevant standard counterparts implemented as well anyway.








Kind Regards, Tobias



































--
====================================================================
The information contained in this electronic mail message and any attachments hereto
is privileged and confidential information intended only for the use of the individual or 
entity named above or their designee.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this communication in error 
please immediately notify us by return  message or by telephone and delete the 
original message from your mail system.  Thank you.
====================================================================











Allen Baum
 

For layout reasons, I can easily imagine a vector unit that has multiply HW for vector registers, but can't easily use them to implement scalar multiply/divide. Whether someone would ever want to implement a system that implements vector multiply/divide but not scalar multiply/divide is, and should be, a completely separate issue; I see no reason why they need to be tied together. IF there are no profiles that have vector mujl without scalar mul, then no one will be implementing that configuration and this is a moot point - but no harm to allow it. There are probably hundreds of configurations that won't be covered by profiles, and we can't obsess about them either. (hundreds are likely a very, very conservative estimate)

On Fri, Aug 21, 2020 at 4:30 PM Andrew Waterman <andrew@...> wrote:


On Fri, Aug 21, 2020 at 2:43 PM Simon Davidmann <simond@...> wrote:
A question to clarify. You state:
      RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.  

This means if I understand you that we need to add F to get F hardware in the vector unit - so RV32IV means V with no F hardware, and RV32IFV includes F hardware.

So for consistency...

What does RV32IV means for M hardware multiply - do I need to RV32IMV to get scalar and vector hardware multiply?

I don’t believe the spec explicitly addresses this question, but I agree it makes sense. Alternatively, V could require M, since it doesn’t make much sense to pay for a vector unit but be too stingy to pay for a multiplier. But that might be less consistent. (My recommendation is that RV32IV continue to mean “no multiplier”, even though it’s a silly configuration.)


RV32IV means no F and no M hardware? - so I need to explicitly include the extensions I need as V assumes nothing but I?

My recommendation is to clarify in the spec that RV32IV is a valid config with no FPU in the vector unit, and RV32IFV is also a valid config with an FPU in both scalar and vector.


Or is something assumed for M?

If we choose to define that V implies M, RV32IV and RV32IMV would be synonyms.


thanks

On Thu, Aug 20, 2020 at 8:48 PM Andrew Waterman <andrew@...> wrote:
Quad-widening ops have been moved to a separate extension, Zvqmac.

I believe the intent is that the capital-V V extension supports the same FP datatypes as the scalar ISA, so e.g., RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.

I’m surprised all those hashtags made it past the spam filter!

On Thu, Aug 20, 2020 at 11:42 AM Strauch, Tobias (HENSOLDT Cyber GmbH) <tobias.strauch@...> wrote:

Apologies if this is old stuff already dismissed. But I give it a try anyway.


Wouldn't it make sense to separate more complex vector instructions from more trivial ones? Already with the very first base release ? Vector instructions can also be helpful in small devices #IOT #Edge #GAP8 #RISCY without the need to fully support floating point instructions or without the need for a quad multiply.


The suggestion would be to basically group vector extensions analogue to the standard instructions (I, M, F, D, Q, …), instead of having an already complex base and then subtract or re-define subsets of instructions again ?


Wouldn't that be in-line with the RISC-V philosophy of modularity and simplicity ? The beauty would be that you have a non-vector and a vector group version.


Possible nomenclature based on order:


M: Standard Multiply Divide Instructions (MUL, ...)

V: Very Basic Vector Instructions (VSETVL, ...)

MV: Standard Multiply Divide Instructions and Very Basic Vector Instructions (MUL, VSETVL, ...

VM: Standard Multiply Divide Instructions, Very Basic Vector Instructions and Vector Integer Multiply\Divide Instructions (MUL, VSETVL, VMUL, ...)


F, D, Q analogue to M as suggested.


The V version will not be a 1:1 match with the standard version and will cover additional aspects. But it can be argued, that when you implement the V version (of M, F, D, Q, ...), then you most likely will have the relevant standard counterparts implemented as well anyway.


Kind Regards, Tobias



--
====================================================================
The information contained in this electronic mail message and any attachments hereto
is privileged and confidential information intended only for the use of the individual or 
entity named above or their designee.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this communication in error 
please immediately notify us by return  message or by telephone and delete the 
original message from your mail system.  Thank you.
====================================================================


Andrew Waterman
 



On Fri, Aug 21, 2020 at 11:32 PM Allen Baum <allen.baum@...> wrote:
For layout reasons, I can easily imagine a vector unit that has multiply HW for vector registers, but can't easily use them to implement scalar multiply/divide. Whether someone would ever want to implement a system that implements vector multiply/divide but not scalar multiply/divide is, and should be, a completely separate issue; I see no reason why they need to be tied together. IF there are no profiles that have vector mujl without scalar mul, then no one will be implementing that configuration and this is a moot point - but no harm to allow it. There are probably hundreds of configurations that won't be covered by profiles, and we can't obsess about them either. (hundreds are likely a very, very conservative estimate)

Under the scheme I'm promulgating, it's true that you couldn't describe your hypothetical machine as implementing capital-letter "V".  Perhaps it could be an RV32I_Zvbase_Zvm machine or something?  It's OK for esoteric combinations to require long ISA strings, I think.


On Fri, Aug 21, 2020 at 4:30 PM Andrew Waterman <andrew@...> wrote:


On Fri, Aug 21, 2020 at 2:43 PM Simon Davidmann <simond@...> wrote:
A question to clarify. You state:
      RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.  

This means if I understand you that we need to add F to get F hardware in the vector unit - so RV32IV means V with no F hardware, and RV32IFV includes F hardware.

So for consistency...

What does RV32IV means for M hardware multiply - do I need to RV32IMV to get scalar and vector hardware multiply?

I don’t believe the spec explicitly addresses this question, but I agree it makes sense. Alternatively, V could require M, since it doesn’t make much sense to pay for a vector unit but be too stingy to pay for a multiplier. But that might be less consistent. (My recommendation is that RV32IV continue to mean “no multiplier”, even though it’s a silly configuration.)


RV32IV means no F and no M hardware? - so I need to explicitly include the extensions I need as V assumes nothing but I?

My recommendation is to clarify in the spec that RV32IV is a valid config with no FPU in the vector unit, and RV32IFV is also a valid config with an FPU in both scalar and vector.


Or is something assumed for M?

If we choose to define that V implies M, RV32IV and RV32IMV would be synonyms.


thanks

On Thu, Aug 20, 2020 at 8:48 PM Andrew Waterman <andrew@...> wrote:
Quad-widening ops have been moved to a separate extension, Zvqmac.

I believe the intent is that the capital-V V extension supports the same FP datatypes as the scalar ISA, so e.g., RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.

I’m surprised all those hashtags made it past the spam filter!

On Thu, Aug 20, 2020 at 11:42 AM Strauch, Tobias (HENSOLDT Cyber GmbH) <tobias.strauch@...> wrote:

Apologies if this is old stuff already dismissed. But I give it a try anyway.


Wouldn't it make sense to separate more complex vector instructions from more trivial ones? Already with the very first base release ? Vector instructions can also be helpful in small devices #IOT #Edge #GAP8 #RISCY without the need to fully support floating point instructions or without the need for a quad multiply.


The suggestion would be to basically group vector extensions analogue to the standard instructions (I, M, F, D, Q, …), instead of having an already complex base and then subtract or re-define subsets of instructions again ?


Wouldn't that be in-line with the RISC-V philosophy of modularity and simplicity ? The beauty would be that you have a non-vector and a vector group version.


Possible nomenclature based on order:


M: Standard Multiply Divide Instructions (MUL, ...)

V: Very Basic Vector Instructions (VSETVL, ...)

MV: Standard Multiply Divide Instructions and Very Basic Vector Instructions (MUL, VSETVL, ...

VM: Standard Multiply Divide Instructions, Very Basic Vector Instructions and Vector Integer Multiply\Divide Instructions (MUL, VSETVL, VMUL, ...)


F, D, Q analogue to M as suggested.


The V version will not be a 1:1 match with the standard version and will cover additional aspects. But it can be argued, that when you implement the V version (of M, F, D, Q, ...), then you most likely will have the relevant standard counterparts implemented as well anyway.


Kind Regards, Tobias



--
====================================================================
The information contained in this electronic mail message and any attachments hereto
is privileged and confidential information intended only for the use of the individual or 
entity named above or their designee.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this communication in error 
please immediately notify us by return  message or by telephone and delete the 
original message from your mail system.  Thank you.
====================================================================


Allen Baum
 

Works for me.

-Allen

On Aug 21, 2020, at 11:41 PM, Andrew Waterman <andrew@...> wrote:

  It's OK for esoteric combinations to require long ISA strings, I think.


Krste Asanovic
 

Anybody is free to use any subset of supported instructions and
element widths/types. The Z names can be extended down to individual
instructions/width if necessary.

However, we have to guide the software ecosystem where to spend the
available finite effort. So we choose and name some common
combinations to inform software/tool providers what to support, and to
enable compliance testing of those combinations.

We can always add new Z names later for subsets that prove popular.
This can happen after the instruction spec itself is ratified, in a
much lighter-weight process.

Krste


On Sat, 22 Aug 2020 00:32:56 -0700, "Allen Baum" <allen.baum@...> said:
| Works for me.
| -Allen

| On Aug 21, 2020, at 11:41 PM, Andrew Waterman <andrew@...> wrote:

| It's OK for esoteric combinations to require long ISA strings, I think.

|


Simon Davidmann Imperas
 

thanks - I am OK with whichever you choose.


On Sat, Aug 22, 2020 at 12:30 AM Andrew Waterman <andrew@...> wrote:


On Fri, Aug 21, 2020 at 2:43 PM Simon Davidmann <simond@...> wrote:
A question to clarify. You state:
      RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.  

This means if I understand you that we need to add F to get F hardware in the vector unit - so RV32IV means V with no F hardware, and RV32IFV includes F hardware.

So for consistency...

What does RV32IV means for M hardware multiply - do I need to RV32IMV to get scalar and vector hardware multiply?

I don’t believe the spec explicitly addresses this question, but I agree it makes sense. Alternatively, V could require M, since it doesn’t make much sense to pay for a vector unit but be too stingy to pay for a multiplier. But that might be less consistent. (My recommendation is that RV32IV continue to mean “no multiplier”, even though it’s a silly configuration.)


RV32IV means no F and no M hardware? - so I need to explicitly include the extensions I need as V assumes nothing but I?

My recommendation is to clarify in the spec that RV32IV is a valid config with no FPU in the vector unit, and RV32IFV is also a valid config with an FPU in both scalar and vector.


Or is something assumed for M?

If we choose to define that V implies M, RV32IV and RV32IMV would be synonyms.


thanks

On Thu, Aug 20, 2020 at 8:48 PM Andrew Waterman <andrew@...> wrote:
Quad-widening ops have been moved to a separate extension, Zvqmac.

I believe the intent is that the capital-V V extension supports the same FP datatypes as the scalar ISA, so e.g., RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.

I’m surprised all those hashtags made it past the spam filter!

On Thu, Aug 20, 2020 at 11:42 AM Strauch, Tobias (HENSOLDT Cyber GmbH) <tobias.strauch@...> wrote:

Apologies if this is old stuff already dismissed. But I give it a try anyway.


Wouldn't it make sense to separate more complex vector instructions from more trivial ones? Already with the very first base release ? Vector instructions can also be helpful in small devices #IOT #Edge #GAP8 #RISCY without the need to fully support floating point instructions or without the need for a quad multiply.


The suggestion would be to basically group vector extensions analogue to the standard instructions (I, M, F, D, Q, …), instead of having an already complex base and then subtract or re-define subsets of instructions again ?


Wouldn't that be in-line with the RISC-V philosophy of modularity and simplicity ? The beauty would be that you have a non-vector and a vector group version.


Possible nomenclature based on order:


M: Standard Multiply Divide Instructions (MUL, ...)

V: Very Basic Vector Instructions (VSETVL, ...)

MV: Standard Multiply Divide Instructions and Very Basic Vector Instructions (MUL, VSETVL, ...

VM: Standard Multiply Divide Instructions, Very Basic Vector Instructions and Vector Integer Multiply\Divide Instructions (MUL, VSETVL, VMUL, ...)


F, D, Q analogue to M as suggested.


The V version will not be a 1:1 match with the standard version and will cover additional aspects. But it can be argued, that when you implement the V version (of M, F, D, Q, ...), then you most likely will have the relevant standard counterparts implemented as well anyway.


Kind Regards, Tobias



--
====================================================================
The information contained in this electronic mail message and any attachments hereto
is privileged and confidential information intended only for the use of the individual or 
entity named above or their designee.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this communication in error 
please immediately notify us by return  message or by telephone and delete the 
original message from your mail system.  Thank you.
====================================================================


--
====================================================================
The information contained in this electronic mail message and any attachments hereto
is privileged and confidential information intended only for the use of the individual or 
entity named above or their designee.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this communication in error 
please immediately notify us by return  message or by telephone and delete the 
original message from your mail system.  Thank you.
====================================================================


mark
 

Just a reminder that we will differentiate between branding (i.e. what we trademark and what members can advertise) and internal use (like uname in linux vs. splash screen, etc.).

the proposed policy is under review in the policies/proposed folder

On Sun, Aug 23, 2020 at 3:26 PM Simon Davidmann Imperas <simond@...> wrote:
thanks - I am OK with whichever you choose.

On Sat, Aug 22, 2020 at 12:30 AM Andrew Waterman <andrew@...> wrote:


On Fri, Aug 21, 2020 at 2:43 PM Simon Davidmann <simond@...> wrote:
A question to clarify. You state:
      RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.  

This means if I understand you that we need to add F to get F hardware in the vector unit - so RV32IV means V with no F hardware, and RV32IFV includes F hardware.

So for consistency...

What does RV32IV means for M hardware multiply - do I need to RV32IMV to get scalar and vector hardware multiply?

I don’t believe the spec explicitly addresses this question, but I agree it makes sense. Alternatively, V could require M, since it doesn’t make much sense to pay for a vector unit but be too stingy to pay for a multiplier. But that might be less consistent. (My recommendation is that RV32IV continue to mean “no multiplier”, even though it’s a silly configuration.)


RV32IV means no F and no M hardware? - so I need to explicitly include the extensions I need as V assumes nothing but I?

My recommendation is to clarify in the spec that RV32IV is a valid config with no FPU in the vector unit, and RV32IFV is also a valid config with an FPU in both scalar and vector.


Or is something assumed for M?

If we choose to define that V implies M, RV32IV and RV32IMV would be synonyms.


thanks

On Thu, Aug 20, 2020 at 8:48 PM Andrew Waterman <andrew@...> wrote:
Quad-widening ops have been moved to a separate extension, Zvqmac.

I believe the intent is that the capital-V V extension supports the same FP datatypes as the scalar ISA, so e.g., RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc.

I’m surprised all those hashtags made it past the spam filter!

On Thu, Aug 20, 2020 at 11:42 AM Strauch, Tobias (HENSOLDT Cyber GmbH) <tobias.strauch@...> wrote:

Apologies if this is old stuff already dismissed. But I give it a try anyway.


Wouldn't it make sense to separate more complex vector instructions from more trivial ones? Already with the very first base release ? Vector instructions can also be helpful in small devices #IOT #Edge #GAP8 #RISCY without the need to fully support floating point instructions or without the need for a quad multiply.


The suggestion would be to basically group vector extensions analogue to the standard instructions (I, M, F, D, Q, …), instead of having an already complex base and then subtract or re-define subsets of instructions again ?


Wouldn't that be in-line with the RISC-V philosophy of modularity and simplicity ? The beauty would be that you have a non-vector and a vector group version.


Possible nomenclature based on order:


M: Standard Multiply Divide Instructions (MUL, ...)

V: Very Basic Vector Instructions (VSETVL, ...)

MV: Standard Multiply Divide Instructions and Very Basic Vector Instructions (MUL, VSETVL, ...

VM: Standard Multiply Divide Instructions, Very Basic Vector Instructions and Vector Integer Multiply\Divide Instructions (MUL, VSETVL, VMUL, ...)


F, D, Q analogue to M as suggested.


The V version will not be a 1:1 match with the standard version and will cover additional aspects. But it can be argued, that when you implement the V version (of M, F, D, Q, ...), then you most likely will have the relevant standard counterparts implemented as well anyway.


Kind Regards, Tobias



--
====================================================================
The information contained in this electronic mail message and any attachments hereto
is privileged and confidential information intended only for the use of the individual or 
entity named above or their designee.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this communication in error 
please immediately notify us by return  message or by telephone and delete the 
original message from your mail system.  Thank you.
====================================================================


--
====================================================================
The information contained in this electronic mail message and any attachments hereto
is privileged and confidential information intended only for the use of the individual or 
entity named above or their designee.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this communication in error 
please immediately notify us by return  message or by telephone and delete the 
original message from your mail system.  Thank you.
====================================================================