I've been busy trying to get to a draft of 0.9. I just pushed a set of memory instructions with "effective element width" encoded statically, though the text needs more read through

On 4/29/20 6:40 AM, David Horner wrote: Perhaps it would be better added by someone who's actually advocating for the feature rather than by me who doesn't have the broader purpose.I didn't mean just

On 2020-04-27 3:56 p.m., Bill Huffman wrote: Perhaps you would be willing to comment on #410 Place stabler RVV control fields in bits [30:12] of vtype. reduction of

In trying to make SEW level interleave by augmenting the instruction set (including casting), I have a few observations. - arithmetic operators need to function at a given SEW and there is no

Sorry, I didn't say what I meant very well. I agree that it's the width that matters. Machines with short vector registers are likely to be SLEN=VLEN even if the complete quickly. In my

| On 4/27/20 7:02 AM, Krste Asanovic wrote: [..] || I created a github issue for this, #434 - text repeated below, || Krste || || Should SLEN=VLEN be an extension? || [...] | It might be the case

Then I agree that the risk of software fragmentation is high with such an extension. The reality is that some machines will indeed be SLEN=VLEN and thus risk some fragmentation. I am indeed proposing

I meant the SLEN=VLEN "extension" to simply be an assertion about the machine's static configuration. Software could then rely on in-register format matching in-memory format. Krste | Sounds like

Sounds like maybe you're thinking that "widening of SLEN to VLEN" is a runtime setting or something like that. There will be no (certainly few) machines where SLEN is variable as the power/area cost

mixed SEW operations (widening & narrowing) have substantial impact on contiguous SLEN=VLEN I read the "SLEN=VLEN" extension as a logical/virtual widening of SLEN to VLEN. The

It might be the case that the machines where SLEN=VLEN would be the same machines where it would be attractive to use vectors for such code - machines where vectors provided larger registers and

Hi David, I don't understand your observation about "mixed SEW operations (widening & narrowing)..." The conditions required for impact seem to me much stronger. Arbitrary widening & narrowing

as some are not on github, I posted this response to #434 here: Observations: - single SEW operations are agnostic to underlying structure (as Krte noted in recent doc

I created a github issue for this, #434 - text repeated below, Krste Should SLEN=VLEN be an extension? SLEN<VLEN introduces internal rearrangements to reduce cross-datapath wiring for wide datapaths

Hi Krste, I have recently learned from my interactions with EPI/BSC folks that cryptographic routines make frequent use of such operations. For one concrete example, they need to reinterpret an e32

Yes. The register is not tainted by having been used as fractional. But what I was meaning was that there is no active use of that space during fractional mode. That temporary switch to slidedown can

| On 2020-04-25 8:46 p.m., krste@... wrote: || On Sat, 25 Apr 2020 18:23:07 -0400, "David Horner" <ds2horner@...> said: [...] | The wasteful of space still applies (As does the dynamic

| The aspect that will probably be most problematic for programmer is the | loss of memory mapping paradigm. | Whereas adjacent  bytes in memory are in the same or adjacent words | (ditto for half

The aspect that will probably be most problematic for programmer is the loss of memory mapping paradigm. Whereas adjacent  bytes in memory are in the same or adjacent words (ditto for half words and

Yes it is. However, it needn't be, and allowing it to not be gives greater flexibility at minimal cost. This was a suggestion to implement #418. [Introduce vlmt (vl multiplicative threshold) / VLMT