This does not only happen on ELEN=32 and VLEN=32, it happened on all
ELEN=32 arch, and one of our internal configurations hit this...
Wait, is there something I keep missing? There must be I guess.
Disregarding the SEW=8 case because that one is clear, but take for example:
ENTRY (RVVMF4HI,
zve32x_zvl64b will have the same requirement as zve32x_zvl32b,
I mean e16,mf4 could be allowed on zve32x_zvl64b, but it also spec
conformance
if implementation decides to raise an illegal instruction on e16,mf4, which
means
e16,mf4 is not safe to use on zve32x/zve32f.
OK I see, thanks. Sometime
Hi Robin
Sorry Kito, that we're having so much back and forth here, it's not my
> intention to block anything (not that I could anyway). I just want to
> make sure I properly understand the rationale (or the spec, rather).
>
No worries, it's a great chance to clarify the spec together :)
Some t
Sorry Kito, that we're having so much back and forth here, it's not my
intention to block anything (not that I could anyway). I just want to
make sure I properly understand the rationale (or the spec, rather).
Oh, ok, I got the point why you confused on this, the new condition is
little bit `i
On Mon, Mar 24, 2025 at 11:35 PM Robin Dapp wrote:
>
> > This does not only happen on ELEN=32 and VLEN=32, it happened on all
> > ELEN=32 arch, and one of our internal configurations hit this...
>
> Wait, is there something I keep missing? There must be I guess.
>
> Disregarding the SEW=8 case be
On Mon, Mar 24, 2025 at 6:53 PM Robin Dapp wrote:
>
> Hi Kito,
>
> > So valid range fractional LMUL for SEW=8, 16 32 are:
> >
> > mf8 = [8, (1/8)*32] = [8, 4] = [], no SEW is valid with mf8 for ELEN = 32
> > mf4 = [8, (1/4)*32] = [8, 8] = only SEW 8 with mf4 is valid
> > mf2 = [8, (1/2)*32] = [8,
Hi Kito,
So valid range fractional LMUL for SEW=8, 16 32 are:
mf8 = [8, (1/8)*32] = [8, 4] = [], no SEW is valid with mf8 for ELEN = 32
mf4 = [8, (1/4)*32] = [8, 8] = only SEW 8 with mf4 is valid
mf2 = [8, (1/2)*32] = [8, 16] = SEW 8 and 16 with mf2 are valid
[1]
https://github.com/riscvarchi
Hi Robin:
Just got few more clarifications from Andrew about the behavior for
the valid* LMUL for ELEN=32,
* valid may not be a precise word, anyway, the spec guarantees that it
should be implemented.
Spec[1] say:
---
When LMUL < SEWMIN/ELEN, there is no guarantee an implementation would
have
Hi Robin,
Thanks for your comment. I think your point is correct, especially the part
about SEWmin.
I will revise this patch again.
On Wed, Feb 5, 2025 at 4:18 PM Robin Dapp wrote:
> > Hi Robin,
> > Sorry, I should have simplified the problem by presenting it in terms of
> > Zve32x, because Zve3
> Hi Robin,
> Sorry, I should have simplified the problem by presenting it in terms of
> Zve32x, because Zve32f implies Zve32x.
> As the specification states, the requirement is to support LMUL ≥ SEW/ELEN.
> Regarding the implementation,
But the spec requirement mentions SEW_min not SEW?
"In gene
Hi Robin,
Sorry, I should have simplified the problem by presenting it in terms of
Zve32x, because Zve32f implies Zve32x.
As the specification states, the requirement is to support LMUL ≥ SEW/ELEN.
Regarding the implementation,
I followed this rule to fix the problem.
In this link: https://godbolt
Hi Monk,
could you detail the issue/patch a bit? Are we generally violating
LMUL >= SEW/ELEN with zve32f (zve32x as well then)? And what's
"implicit zve32f"? In the test case it's specified explicitly.
> According to Section 3.4.2, Vector Register Grouping, in the RISC-V
> Vector Specification
12 matches
Mail list logo
