Note: lists.riscv.org will be down for maintenance on Monday, September 26th, starting at 9AM Pacific Time (4PM Monday September 26, 2022 UTC), for approximately one hour.
- [riscv/riscv-v-spec] For V1.0 - Make unsigned scalar integer in widening instructions 2 * SEW (#427) (and signed)
Re: [riscv/riscv-v-spec] For V1.0 - Make unsigned scalar integer in widening instructions 2 * SEW (#427) (and signed)
toggle quoted messageShow quoted text
again this is meant as informational for when this goes to vote.
this should be discussable now in email with questions and comments.
please include this in the ratification materials (place in a github a sub folder labeled change-rationales).
this is a continual improvement process. please send stephano and I email on how to improve the resulting content or the process at any time.
On Thu, Aug 6, 2020 at 9:23 PM David Horner <ds2horner@...
I filled out the RISC-V
Policy: Change and Extension Rationale
as best I could for the issue #427.
I believe it is accessible by all. But I will also paste the
Name: Change and
Extension Rationale Submission for ricsv-v-spec issue #427
In GitHub riscv-v-spec issue #427 originally April 21,2020;
Closed: July 24;
reconsideration July 30;
As Change Rationale Aug.
memeber of Vector TG.
prior to V1.0 submission for ratification
and/or Freeze Milestones.
Idoes not need
It is a
refinement to a set of Integer Widening instructions.
questions please explain your answers where appropriate (like
why did you say yes):
functionality gap? Rather it is an apparent formulation
that can improve application performance by avoiding vtype
horizontal attribute enhancement affecting performance.
standard integer scalar range is available for widening
to ratified ISA specification, Vector extension in
request is for a completely new rendering of proposed Vector features.
This can be
done with already proposed instructions?
executing the current widening with integer identity value
multiply, zero otherwise)
switch to twice current Selected Element Width (SEW)
perform corresponding adjustment on step i) widened vector
by or add/subtract widened integer value, as appropriate)
switch to original SEW.
which benefit are restricted to V users
2*SEW integer values are handled in widening scalar ops.
to affect base or derived or custom profiles ?
tests and compiler generation will need to handle an
enlarged integer scalar register.
in the number of cycles needed for any handler entry
and exit, and changes in the number of save/restores
required to support this extension are typical of other vector
known resources who have time to implement either or
both of the above to work.
the impact on logic/gates to be small. Less invasive that
ordinal based mask encoding. Much less disruptive than
removing SLEN visibility. More comparable to the mixed
width vrgatherei16 instruction that is being added.
not be optional.
It is no
more discoverable than any of the other base vector
for widening multiply were the problem of leveraging the
multiply units needed for the next higher SEW for the
current SEW. Concern is that the SEW level multiply unit
will have to be enlarged. Initial estimates were by a
factor of 2.
the multiplication result is widening to 2*SEW, some of
the needed circuitry already is present for an expanded
integer input. The expanded multiplication result will be
truncated to 2*SEW, and so, for these teo reasons doubling
of the circuit is not required. As a result a mitigation
that dynamically selected paths based on zero (or sign
extended) upper SEW integer bits is not required. Such a
scheme was correctly rejected as inappropriate for most
implementations, but it does not materially factor into
the discussion as partitioning the next higher multiplier
circuitry should be adequate for all anticipated
Mark I Himelstein
CTO RISC-V International
Join firstname.lastname@example.org to automatically receive all group messages.