The key insight from the 21264 design is that the valid bits are cleared periodically. I appreciate that you were willing to meet me more than halfway, but I actually think your original idea would

We'll meet per the calendar entry. Agenda is to go over any remaining unsettled open issues, Krste

On 11/5/20 10:51 PM, Bill Huffman wrote: I see it's called a "stWait table" in the hardware reference manual. I see how that works for waiting loads. I'm guessing that you're thinking of a PC based

On 11/5/20 8:33 PM, Andrew Waterman wrote: Do you know of a reference for how the store-wait predictor works? I can't find any reference to it in the 21264 hardware reference manual, though I found a

I was thinking of something along the lines of the Alpha 21264's store-wait predictor: every N cycles (with N probably somewhere in the range of [2^10, 2^14]), clear the valid bits. Gotcha. And while

On 11/5/20 5:31 PM, Bill Huffman wrote: The possibility of a second store (for which there's easy encoding space) would allow the bit to be set or cleared depending on which store instruction was

On 11/5/20 4:36 PM, Andrew Waterman wrote: How are you thinking that bit gets set/cleared? The same store instruction is used whether or not the compiler will be able to put in a hint. I'm hoping

If your per-vector-register predictor works well to begin with, I would think you could extend it with a valid bit that indicates whether to use the prediction or the encoded hint, and it would

On 11/5/20 3:35 PM, Andrew Waterman wrote: My idea of a predictor is one predicted size per vector register (or maybe two or three sizes operating as a stack). Let's say for simplicity, we have both

I'm probably being obtuse, because you've surely already thought this through: if you can build an EEW predictor, why can't you build an ignore-the-encoded-EEW predictor? If you have a PC-indexed and

I've been thinking through the cases where a wide implementation that wants "slices" could have to introduce a hiccup to rearrange bytes because of an EEW change (since SLEN is gone). The ones I know

Thanks Tim, I think that sums it up nicely. I just wanted to put a pointer out to the original post that I made on isa-dev regarding opcode sharing /

Hi all, If I use EDIV to compute SpMV y = A * x as size r * c blocks, I might have to load size r of y and size c of x, these are shorter than VL = r * c, is there an efficient way to do this by

The email list has the archived discussion, which should include discussion of EDIV. The main reason not to include in v1.0 is that it has many details to work through, and resolving these would delay

Hi all, Thank you Nick for the reply. I saw EDIV will not be included in v1.0, any issues to be resolved? Can I have a look at the discussion page on EDIV? Thanks a lot, Dawei

On 2020-10-26 12:48 a.m., Allen Baum wrote: That is one approach. It is a consideration that has recently been mentioned wrt misa. I remember Luke Kenneth Casson Leighton

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

Are we talking about something that is effectively bank switching the opcodes here? Something like that was proposed very early on, using a CSR (like MISA maybe - the details are lost to me) to enable

There is text in some places stating this, but it is also something that needs to get reemphasized in the base ISA manual intro. Krste

Did you keep/add text encouraging implementations to indeed raise illegal on reserved encodings ? I went through the patch (rather quickly) and did not see it. Roger