Sure. You could guarantee forward progress, e.g. by allowing no more than 10 successive "first fault" with VL=0, and requiring trap on element zero on the 11th. That check could be in

Here's the strlen example from spec: .text .balign 4 .global strlen # size_t strlen(const char *str) # a0 holds *str strlen: mv a3, a0 # Save

So all the vleff use cases end up then using a vmpopc of some sort to determine the exit condition and never use the trimmed VL ? (other than, of course, to control within the while how many elements

I don't think the cases where there was no fault look any different to software than the fault cases. Either can happen anywhere and the while loop may continue. The while loop isn't ended by a

We're all in agreement that if the spec says "pick where you stop" we'd all pick to trim to VL=3. I was under the impression this was not yet closed (in light of the "stop at cache misses"

As you get to pick where vl is trimmed, you would probably choose the vl=3 case here to simplify implementation. Krste | Bill you said element 9, but did you mean element labeled "a" which is the

Roger, I think it's an implementation choice whether vl is trimmed to 3 or 6 (or theoretically other values). I don't know a reason why the implementation couldn't always trim vl to the same value

Bill you said element 9, but did you mean element labeled "a" which is the 11th element in the vector? (I agree with that). However, I would NOT agree that a masked out element has been written, even

Here's where the "implementation" cost comes in (at least in our implementation; others, of course, may have more clever ways of doing this) -> If you pick "vl=3", then the vstart and vltrim

The way the discussion has been going, I think either would be permissible. Not only that, but it would have been permissible for element 9 already to have been overwritten with 1's (if vma allows

Here's a question for the group: I did in as a picture... hopefully it will go through the mailing list:

The mask could be built with sew=16, as the mask is ordinal based. And there are tricks to set it up, for example a direct load (register move) to v0 to set the correct bit. The mask could be built

Hi, what is a reasonable sequence to insert an element into an arbitrary position in the vector? I considered the following sequence (assume the input vector is v12) vid.v v1 vmseq.vx v0, v1,

The forward progress is to advance to another task. In the case of machine mode it can potentially "resolve" the cause of the vl=0 return and re-execute the loop (without the overhead of the

| First I am very happy that "arbitrary decisions by the | micro-architecture" allow reduction of vl to any [non-zero] value. | Even if such appear "random". [...] | A check for vl=0 on platforms

First I am very happy that "arbitrary decisions by the micro-architecture" allow reduction of vl to any [non-zero] value. Even if such appear "random". Exactly. I see this openness/lack of

I agree, however, it still does not answer the ISA visible behavioural question: "Is the trap allowed to set vl=0 on return?" Can this be compliant behaviour for certain platforms? If so, then it

Date: 2020/10/9 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~12 Current issues on github: https://github.com/riscv/riscv-v-spec # 576 vlsegff

Date: 2020/10/2 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~12 Current issues on github: https://github.com/riscv/riscv-v-spec Issues discussed; #

(sending replies to vector list - as this is off topic for CMOs) My opinion is that baking SIMT execution model into ISA for purposes of exposing microarchitectural performance (i.e., cache