|
RISC-V Vector Extension post-public review updates - fault flagging
First there is currently no ff gather. But if there were, the vl would need to be truncated to the first in sequence that faulted. That would potentially require back tracking by the handler from the
First there is currently no ff gather. But if there were, the vl would need to be truncated to the first in sequence that faulted. That would potentially require back tracking by the handler from the
|
By
David Horner
· #760
·
|
|
RISC-V Vector Extension post-public review updates - fault flagging
The trap if first address bad is stipulated behaviour. The other are not specified in the vector extension , but 1. the counter is part of the generalized performance spec. 2. Always trap but allow re
The trap if first address bad is stipulated behaviour. The other are not specified in the vector extension , but 1. the counter is part of the generalized performance spec. 2. Always trap but allow re
|
By
David Horner
· #758
·
|
|
RISC-V Vector Extension post-public review updates - fault flagging
that should have been "The HS is in control, it can "leak" or not as it sees fit" obviously.
that should have been "The HS is in control, it can "leak" or not as it sees fit" obviously.
|
By
David Horner
· #756
·
|
|
RISC-V Vector Extension post-public review updates - fault flagging
The VS having this awareness can be very beneficial. It allows the OS to better manage its resources. It can switch to handling other supervisory actions while that data is paged/staged in. Never the
The VS having this awareness can be very beneficial. It allows the OS to better manage its resources. It can switch to handling other supervisory actions while that data is paged/staged in. Never the
|
By
David Horner
· #755
·
|
|
RISC-V Vector Extension post-public review updates - fault flagging
yes. I will below. It could depending upon what implementation details are designed into the hart. Control Mechanisms: If the first address of the vector load is problematic, whether first fault or no
yes. I will below. It could depending upon what implementation details are designed into the hart. Control Mechanisms: If the first address of the vector load is problematic, whether first fault or no
|
By
David Horner
· #751
·
|
|
RISC-V Vector Extension post-public review updates - fault flagging
However, we did discuss its merit; if it would trump the encoding dificulties, see below - there are two aspects here - a) checking array indexes are within bounds, which absent proof that the indexes
However, we did discuss its merit; if it would trump the encoding dificulties, see below - there are two aspects here - a) checking array indexes are within bounds, which absent proof that the indexes
|
By
David Horner
· #745
·
|
|
RISC-V Vector Extension post-public review updates
I am curious as well. It makes sense when the whole vector is participating and masking is the only means to limit processing, but we have vlen. Specifically no First Fault variant was included so tha
I am curious as well. It makes sense when the whole vector is participating and masking is the only means to limit processing, but we have vlen. Specifically no First Fault variant was included so tha
|
By
David Horner
· #741
·
|
|
RISC-V Vector Extension post-public review updates - 32bit opcode decision
Yes, absolutely. Many vector models historically have been co-processors with their own internal status. RVV integration is also a major accomplishment. I was a part of that. However, a consensus with
Yes, absolutely. Many vector models historically have been co-processors with their own internal status. RVV integration is also a major accomplishment. I was a part of that. However, a consensus with
|
By
David Horner
· #735
·
|
|
Is it safe to extend LMUL's maximum value based on current rc2 version?
Thank you for this very important consideration. Yes. The expectation is that many of the current constraints will be relaxed in future versions. It is here that I most appreciate your interest. I hav
Thank you for this very important consideration. Yes. The expectation is that many of the current constraints will be relaxed in future versions. It is here that I most appreciate your interest. I hav
|
By
David Horner
· #695
·
|
|
Vector TG Meeting tomorrow
I apparently missed the meeting that I thought was at noon eastern. There are of course the remaining open for v1.0 issues. I gather what was discussed was if we could reasonably move to public review
I apparently missed the meeting that I thought was at noon eastern. There are of course the remaining open for v1.0 issues. I gather what was discussed was if we could reasonably move to public review
|
By
David Horner
· #665
·
|
|
Vector TG Meeting tomorrow - imprecise trap description/use.
For discussion: The text states: reporting an error and terminating execution is the appropriate response. Issue #598 to be resolved after v1.0 and issue #364 which is tagged with "resolve for v1.0" a
For discussion: The text states: reporting an error and terminating execution is the appropriate response. Issue #598 to be resolved after v1.0 and issue #364 which is tagged with "resolve for v1.0" a
|
By
David Horner
· #661
·
|
|
No vector TG meeting tomorrow - preparing to start public review
I am disappointed that the meeting was cancelled. I am concerned that jnk0le's contributions/concerns, in particular, have been dismissed and to the extent that they were objections to the draft have
I am disappointed that the meeting was cancelled. I am concerned that jnk0le's contributions/concerns, in particular, have been dismissed and to the extent that they were objections to the draft have
|
By
David Horner
· #653
·
|
|
回复:Re: 回复:[RISC-V] [tech-vector-ext] RISC-V Vector Spec version 1.0-rc1-20210608
@guy: I don't know what each letter stands for, but the link has this: TRN1 Interleave even elements from two vectors . I assume there is TRN for odds and maybe mixed?
@guy: I don't know what each letter stands for, but the link has this: TRN1 Interleave even elements from two vectors . I assume there is TRN for odds and maybe mixed?
|
By
David Horner
· #649
·
|
|
Background for Policy/Workflow revisions on Github close concern.
Andrew Waterman called Thursday and we discussed many issues including challenges with Issues in Github. We determined that both were unaware of some relevant aspects [neither of us intentionally blin
Andrew Waterman called Thursday and we discussed many issues including challenges with Issues in Github. We determined that both were unaware of some relevant aspects [neither of us intentionally blin
|
By
David Horner
· #644
·
|
|
LLVM with RVV intrinsic support
Excellent. Congratulations, and thank you!!
Excellent. Congratulations, and thank you!!
|
By
David Horner
· #596
·
|
|
The scenarios of GEMM for u/int8 data
Can we see the git of your work? Does this mean the 32 vector registers are not enough, or that the number of elements for the given input vector length are not enough? Note vdot.vv is experimental. I
Can we see the git of your work? Does this mean the 32 vector registers are not enough, or that the number of elements for the given input vector length are not enough? Note vdot.vv is experimental. I
|
By
David Horner
· #529
·
|
|
Vector Task Group minutes 2020/12/04
I concur. Software can effect tail-undisturbed by A pre conditioning the load, B loading into temp register then use bitwise logic into target, C save last byte of target , lde1, read last byte, write
I concur. Software can effect tail-undisturbed by A pre conditioning the load, B loading into temp register then use bitwise logic into target, C save last byte of target , lde1, read last byte, write
|
By
David Horner
· #527
·
|
|
[RISC-V] [tech-*] STRATEGIC FEATURE COEXISTANCE was:([tech-fast-int] usefulness of PUSHINT/POPINT from [tech-code-size])
That is one approach. It is a consideration that has recently been mentioned wrt misa. I remember Luke Kenneth Casson Leighton <lkcl@...> was in on the discussions. A variety of csr and related a
That is one approach. It is a consideration that has recently been mentioned wrt misa. I remember Luke Kenneth Casson Leighton <lkcl@...> was in on the discussions. A variety of csr and related a
|
By
David Horner
· #489
·
|
|
[RISC-V] [tech-*] STRATEGIC FEATURE COEXISTANCE was:([tech-fast-int] usefulness of PUSHINT/POPINT from [tech-code-size])
My take: This is analogous to ascii(7-bit) and EBCIDIC(8-bit) both competing in the 8 bit byte addressable character space. Initial solutions were fragmentation, then code pages (select-able character
My take: This is analogous to ascii(7-bit) and EBCIDIC(8-bit) both competing in the 8 bit byte addressable character space. Initial solutions were fragmentation, then code pages (select-able character
|
By
David Horner
· #488
·
|
|
[RISC-V] [tech-*] STRATEGIC FEATURE COEXISTANCE was:([tech-fast-int] usefulness of PUSHINT/POPINT from [tech-code-size])
These are all important considerations. However, what they have in common when considering Allen's question: is that they are all tactical considerations are in the context of our current framework of
These are all important considerations. However, what they have in common when considering Allen's question: is that they are all tactical considerations are in the context of our current framework of
|
By
David Horner
· #482
·
|