|
Zvediv extension discussions
The current vector TG is only tasked with one more deliverable, which is the IEEE FP16 half-precision extensions (Zvfh, Zvfhmin). This is effectively already defined in ratified specification, and so
The current vector TG is only tasked with one more deliverable, which is the IEEE FP16 half-precision extensions (Zvfh, Zvfhmin). This is effectively already defined in ratified specification, and so
|
By
Krste Asanovic
· #788
·
|
|
The Width of vcsr and vstart
Thanks for spotting the oversight. The spec was updated to indicate these should be treated as XLEN-bit wide registers. There is no effective difference right now given that upper bits are not current
Thanks for spotting the oversight. The spec was updated to indicate these should be treated as XLEN-bit wide registers. There is no effective difference right now given that upper bits are not current
|
By
Krste Asanovic
· #778
·
|
|
[RISC-V] [tech-unprivileged] [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability
I'll note that ARM appears to detect tininess before rounding, while x86 does so after rounding. Also, current ARM compilers don't support exception trapping on AArch64. https://developer.arm.com/docu
I'll note that ARM appears to detect tininess before rounding, while x86 does so after rounding. Also, current ARM compilers don't support exception trapping on AArch64. https://developer.arm.com/docu
|
By
Krste Asanovic
· #776
·
|
|
[RISC-V] [tech-unprivileged] [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability
Yes, this would be the obvious path to take. Some use cases, including maybe this one, might prefer FP traps to be horizontal into user mode. There is the old MIPS FPU pipeline trick of conservative e
Yes, this would be the obvious path to take. Some use cases, including maybe this one, might prefer FP traps to be horizontal into user mode. There is the old MIPS FPU pipeline trick of conservative e
|
By
Krste Asanovic
· #771
·
|
|
Vector Memory Ordering
| Reviving this old thread with a question and a suggestion: | Question: What is the use case for supporting non-idempotent memory in a RISC-V Vector implementation as a part of a general-purpose | ri
| Reviving this old thread with a question and a suggestion: | Question: What is the use case for supporting non-idempotent memory in a RISC-V Vector implementation as a part of a general-purpose | ri
|
By
Krste Asanovic
· #765
·
|
|
RISC-V Vector Extension post-public review updates
Earlier Intel Larrabee design had variant that required loop around unsuccessful gather according to mask bits. I believe some folks on this list were responsible for that... Krste
Earlier Intel Larrabee design had variant that required loop around unsuccessful gather according to mask bits. I believe some folks on this list were responsible for that... Krste
|
By
Krste Asanovic
· #750
·
|
|
RISC-V Vector Extension post-public review updates - fault flagging
A paranoid hypervisor could restrict ff loads to always reduce to vl=1, or only after x failed probes, for example. Krste
A paranoid hypervisor could restrict ff loads to always reduce to vl=1, or only after x failed probes, for example. Krste
|
By
Krste Asanovic
· #748
·
|
|
RISC-V Vector Extension post-public review updates
SVE uses a special dedicated FFR register to hold these first-faulting load mask bits. RVV just reuses vector length register in a natural way. Krste
SVE uses a special dedicated FFR register to hold these first-faulting load mask bits. RVV just reuses vector length register in a natural way. Krste
|
By
Krste Asanovic
· #746
·
|
|
RISC-V Vector Extension post-public review updates
The primary reason was lack of encoding space for non-unit-stride fault-on-first instructions. The security concern was being able to probe addresses to find accessible regions without free of being k
The primary reason was lack of encoding space for non-unit-stride fault-on-first instructions. The security concern was being able to probe addresses to find accessible regions without free of being k
|
By
Krste Asanovic
· #743
·
|
|
RISC-V Vector Extension post-public review updates
Not necessarily with a larger mask register specifier. For example, with 3b mask register specifier, we could expand to encode v0-v6 as mask sources with 111 meaning unmasked. Krste
Not necessarily with a larger mask register specifier. For example, with 3b mask register specifier, we could expand to encode v0-v6 as mask sources with 111 meaning unmasked. Krste
|
By
Krste Asanovic
· #738
·
|
|
RISC-V Vector Extension post-public review updates
| From: Grigorios Magklis <grigorios.magklis@...> | Sent: Tuesday, November 16, 2021 12:03 PM | What is the thinking for when we go to >32-bit encodings with respect to vtype | and masks
| From: Grigorios Magklis <grigorios.magklis@...> | Sent: Tuesday, November 16, 2021 12:03 PM | What is the thinking for when we go to >32-bit encodings with respect to vtype | and masks
|
By
Krste Asanovic
· #736
·
|
|
RISC-V Vector Extension post-public review updates
|| 1) Mandate all implementations raise an illegal exception in this || case. This is my preferred route, as this would be a minor errata for || existing implementations (doesn't affect software), and
|| 1) Mandate all implementations raise an illegal exception in this || case. This is my preferred route, as this would be a minor errata for || existing implementations (doesn't affect software), and
|
By
Krste Asanovic
· #730
·
|
|
RISC-V Vector Extension post-public review updates
| From an ISA definition point of view it doesn't make sense to forbid properly formed operations to benefit a | specific hardware implementation. It's an ugly hack. A common goal in ISA design is avo
| From an ISA definition point of view it doesn't make sense to forbid properly formed operations to benefit a | specific hardware implementation. It's an ugly hack. A common goal in ISA design is avo
|
By
Krste Asanovic
· #728
·
|
|
RISC-V Vector Extension post-public review updates
In this case, the trap cause can be determined by looking at the vtype value and the instruction encoding (most only need to look at instruction encoding), independent of implementation. No vtype prob
In this case, the trap cause can be determined by looking at the vtype value and the instruction encoding (most only need to look at instruction encoding), independent of implementation. No vtype prob
|
By
Krste Asanovic
· #726
·
|
|
RISC-V Vector Extension post-public review updates
I guess simpler examples are anytime you use v0 as mask and a data source. These aren't useful use-cases, so existing software shouldn't have been doing this (except test code). Krste | On Mon, Nov 15
I guess simpler examples are anytime you use v0 as mask and a data source. These aren't useful use-cases, so existing software shouldn't have been doing this (except test code). Krste | On Mon, Nov 15
|
By
Krste Asanovic
· #724
·
|
|
RISC-V Vector Extension post-public review updates
I'm not sure if C intrinsics can generate this case, but there are other cases where dynamic value settings can result in illegal instruction traps, so the result would be the same that implementation
I'm not sure if C intrinsics can generate this case, but there are other cases where dynamic value settings can result in illegal instruction traps, so the result would be the same that implementation
|
By
Krste Asanovic
· #722
·
|
|
RISC-V Vector Extension post-public review updates
I went with #3 in the updated text - this is the smallest delta from the frozen spec. Note that the worst case was something like: vfwmacc.vv v0, v0, v0, v0.t with SEW=32b, v0 is read/written as a 64b
I went with #3 in the updated text - this is the smallest delta from the frozen spec. Note that the worst case was something like: vfwmacc.vv v0, v0, v0, v0.t with SEW=32b, v0 is read/written as a 64b
|
By
Krste Asanovic
· #721
·
|
|
RISC-V Vector Extension post-public review updates
There’s no benefit to setting vill versus just taking a trap in this case. Vill is there so we don’t have to add the first trap on a write of a particular data value, and also to provide a discovery m
There’s no benefit to setting vill versus just taking a trap in this case. Vill is there so we don’t have to add the first trap on a write of a particular data value, and also to provide a discovery m
|
By
Krste Asanovic
· #718
·
|
|
RISC-V Vector Extension post-public review updates
I'm OK with going with #3 - it provides most flexibility to deal with in future, even if we just go with illegal instruction exception, and avoids adding tests to the compatibility suite. Krste | On M
I'm OK with going with #3 - it provides most flexibility to deal with in future, even if we just go with illegal instruction exception, and avoids adding tests to the compatibility suite. Krste | On M
|
By
Krste Asanovic
· #714
·
|
|
RISC-V Vector Extension post-public review updates
| We do have a choice of: | 1) Mandate all implementations raise an illegal exception in this | case. This is my preferred route, as this would be a minor errata for | existing implementations (doesn'
| We do have a choice of: | 1) Mandate all implementations raise an illegal exception in this | case. This is my preferred route, as this would be a minor errata for | existing implementations (doesn'
|
By
Krste Asanovic
· #710
·
|