laundry list of concerns following TG Minutes 2020/6/26

David Horner

I trust this is not just noise.

A laundry list of concerns

Assess objectives and those met as we approach v1.0 of RVV

Polymorphism has not made it into RVV V0.9

Tagging registers with a datatype is not likely for v1.0

Is it still a vision for a future evolution of v1.0

Is it likely for INST64?

Is there anything we need to put in place now to assist its inclusion later?

A design for all ranges of processors IOT to Supercomputers.

The full V0.9 is too large for smallest implementations

The specification implies float is optional when F not implemented.

Float_in_Integer would lessen the burden on small designs.

Does Float in V become mandatory if FinI is implemented/.

RVV has a complex model:


register types: scalar vs vector vs mask

register groups: and alignment on 8/4/2 boundaries.

(similar but not synonymous with LMUL.

csrs: vtype (including ediv), vcsr, vxrm, vxsat, vstart and vlenb,.

Behaviour qualifiers: tail and mask undisturbed/agnostic

vsetvli instruction(s) – multipurpose persistent settings and algorithm for vl.

Scope and nature of V1.0

The current design is large.

The only optional functionality is Zvediv.

Is a smaller base possible/desirable.

Do we punt to “profiles” to determine what needs to be included?

RVI intends to be a base for extensions and experimentation.

Are we expecting V1.0 to be a similar base for diversity and experimentation.

Are there sufficient facilities in place to allow this?

RVI relies on traps for emulation/extension.

RVV explicitly tries to avoid traps.

What needs to be added to vcsr or elsewhere?

On 2020-06-26 11:05 p.m., Krste Asanovic wrote:

Date: 2020/6/26
Task Group: Vector Extension
Chair: Krste Asanovic
Co-Chair: Roger Espasa
Number of Attendees: ~15
Current issues on github: