Possible RV32E modifications

That loses the useful property that all valid RV32E programs (which do
not attempt to execute an undefined instruction) are valid RV32I
programs. That is, once you used a RV32E core for your application, you
couldn't upgrade later to a RV32I if you needed more power (without
recompiling or even rewriting your code).

--
Cesar Eduardo Barros
ces...@cesarb.eti.br

Recompilation is feasible only if the code isn't written in assembly,
and if you actually have the full source code. Even then, recompilation
always carries a risk of changing the code's behavior, whether because
of undefined behavior or because the new sequence of instructions has
different timings or alignment.

We got that compatibility back by adding the SXL and UXL fields in
mstatus and sstatus, allowing optional support for RV64 processors to
execute unmodified RV32 code. I expect such support to be common in
workstation-class systems.


-- Jacob

As of this writing, the draft for RVV already supports integer and fixed
point arithmetic. I believe that RVV was always intended to have
integer support, and therefore fixed point support.


-- Jacob

The slides I've seen doesn't explicitly mandate fixed point, but it is pretty clear about how different formats can be added in as custom extensions.
Integer and floating point formats are spec'ed (by IEEE for FP and by every processor in existence for intenger). There isn't "a" fixed point format - there are lots of them.
>To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/5A20E5F2.6070307%40gmail.com.


--
**************************************************
* Allen Baum tel. (908)BIT-BAUM *
* 248-2286 *
**************************************************

Well, that hardware is wasted on the existing RV32E hardware anyway.
The full set of registers was implemented.

IMHO, the RV32E spec should require them and the ABI should use them.
It's really a whole different architecture otherwise.

That "benchmark" is suggestive of reality, but feature sets and level
of optimization effort vary from one architecture to another.

Thumb and x86 got the most effort:
http://www.deater.net/weave/vmwprod/asm/ll/README

Before assuming RISC-V is lacking, perhaps you should see if you
can improve the results. Maybe we should consider it a contest.

It's also a benchmark for just one particular task.

People really like to keep running their old software, preferably as-is.
We've seen a lot of use on 32-bit ABIs on 64-bit CPUs in Linux, and
I suspect once there is nommu Linux port to RV32E people would really
like to have their binaries written for that still work on full scale
RV32G and RV32G CPUs. And yes, designing the syscall ABI for that will
be interesting.

Also sooner or later I'd expect people running existing RTOS or bare
metal RV32E setups in VMs on RV32G or RV64G setups. On x86 I've seen
plenty of these setups where existing legacy code is moved into a VM,
and people start doing this work on ARM already as well.

That's certainly true but that's where I see a difference with embedded
space and especially
embedded memory devices. At some point, it might be difficult to make
everybody happy.
It is then important to know which segment RISC-V want to crack or risk
penetrating none.
The legacy issue you mention only becomes true after there are legacy
applications based on RISC-V.

Unless I am mistaken, fixed point is simply a different interpretation
of integer values, as N/M instead of N, so integer calculations work
equally well for fixed point. In other words, fixed point is software
and always uses integer hardware. I gather that a similar assumption is
being made in developing RISC-V, so if this is wrong, now would be a
good time to provide counter-examples.


-- Jacob

There's a thread[0] on the unums mailing list that summarizes a number of
concerns with posits, all of which I agree with.

Additionally, from a CPU design perspective the fact that all NaNs are
signaling seems... suboptimal. This was also brought up[1] on the list, by
Clifford Wolf. (Who may well have been considering how they might be used with
RISC-V.)

Both threads had some discussion on the topics, but the alternatives to the
posit approach (using the extended reals rather than the projective reals,
etc.) have not been fully developed, and I found Gustafson's answers as to why
the current approach of posits is sufficient less than compelling.

[0] https://groups.google.com/forum/#!topic/unum-computing/5tG7s2hnM6Q
[1] https://groups.google.com/forum/#!topic/unum-computing/peOw8OlfM7E

Hi,

jfyi: I've had further off-list discussions with John Gustafson. (That
reminds me that I still owe him a reply to a mail from over a week ago,
oops.)

The current status is that he agrees that the +/-INF pattern should be
"sticky" in the posit case. I.e. dividing by +/-INF would still return
+/-INF, turning it effectively into a non-signaling NaN. (I don't care
about the name as long as the semantics is the "right" one.) This means
posits would be reals + a special pattern for the empty set (call it NaN
or +/-INF, i don't care), and valids would be intervalls on projective
reals. Note that with valids you would have patterns for the empty set and
for the set of all numbers.

We have also discussed the architectural implications of signaling NaNs and
that I would prefer a solution where the software would check for empty set
patterns if signaling behavor is desired, but the floating point hardware
would never need to raise a hardware exception, thus simplifying control
logic.

Re his "outlandish claims" about halving memory bandwidth: His claim is
that there are many applications where the approx 4 bits of additional
precision for 32 bit floats make the difference so that those applications
can use 32 bit posits instead of 64 bit ieee floats. It is obviously the
case that for those applications switching from 64 bit ieee floats to 32 bit
posits would halve the required memory bandwidth on data-intensive kernels.

I can't tell yet for how many applications this is the case, but I
certainly have worked on projects where 32 bit ieee floats where
insufficiently precise by just about one decimal digit (3.3 bits).

regards,
- clifford
> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/1629870.c4lJlKtLsA%40arkadios.

--
"Beware of bugs in the above code; I have only proved it correct,
not tried it." - Donald E. Knuth

I think that we are both right for the scalar unit; fixed-point formats
are a matter of software. For RVV, fixed-point multiply will require
the use of expanding vector operations and a subsequent extraction
step. I would be particularly interested if the same instruction could
provide both vector-extract-fixed-point and vector-reduce-bignum.
Double shift is certainly something the vector unit could do, even with
a shift amount read from a (scalar) register or another vector for an
element-by-element shift.


-- Jacob

Oh- I thought we were talking about adding some fixed point support to the vector unit- (which would handle the final shift) but we would need to which format (or formats-which was my point).

Typical formats are 1.x, or 0.x in both signed and unsigned forms (and probably something else for audio and DSP ).
You are suggesting bignum results for mul, which returns an I shifted double width result. If that a defined format, then just typing the result register with it should get you the correct result.

For double shift: i am unaware of any non-load/store that uses general registers . You could define it in the vector refs, but the shift amt would need to be in the vector refs.

But, as long as I have your attention:
We’ve not defined ops the move data between vector and general regs (either integer or float). Do we need that, or would we be using one or the other (which opens other cans of worms).

And, there isn’t a good definition of the semantics of implicit conversion.
E.g. Vadd a,b,c where all three are different types
A) convert both b&c to type a and then add, or
B) convert b to type c, add, and convert the result to a?
( or convert c to type b- we would need some strict type priority rules)
C) do it one way if src length is longer/ shorter than dest length.

The order of conversion is also an issue if b,c have the same type, but a different destination type.

This starts to get seriously weird if the dest is a scalar.

-Allen

Since software determines what fixed-point format is in use, I suggest
finding the required (likely bitwise) low-level operations that will
allow software to use an expanding vector integer multiply, then extract
the desired fixed-point result easily. To make this fully effective,
the vector unit should be able to handle integer elements twice XLEN in
length.
I was also suggesting being able to use the vector unit for bignum
calculations, with bignums longer than the maximum vector length by
"rotating" the data through the vector unit from/to memory. The
vector-reduce-bignum operation handles merging the carries back in after
an expanding multiply, or part of doing so, possibly producing an
additional carry state vector from its addition step. A
vector-process-carry operation converts a carry state vector into a
vector that can be element-wise added to the result of vector-add to
produce the correct result. I worked out the math in message-id
<57EB10A7...@gmail.com>
<URL:https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/57EB10A7.1000801%40gmail.com>.

The vector-reduce-bignum operation can be emulated using a unit-stride
vector store, constant-stride vector loads, and a vector-add, but this
involves memory traffic for an operation that can be done faster inside
the vector unit.

Bignums can also be used to implement arbitrary-precision fixed-point
and floating-point, so strong support for bignum calculations in RVV
will benefit a wide range of applications.

> For double shift: i am unaware of any non-load/store that uses general registers. You could define it in the vector refs, but the shift amt would need to be in the vector refs.
>

I am disappointed -- the original RVV presentation I saw suggested that
scalar values would be generally usable as inputs to vector calculations.
Aside from the general ability to use scalar registers as calculation
inputs, I would expect moves between vector and scalar units to mostly
go through memory, although vector-get-element might be useful, using an
integer scalar register to select an element index in a vector register
and transferring one element to either an integer or FP register. The
corresponding vector-put-element can be performed by using predicated
vector-splat, or could be a similar instruction.
An idea:

The vector unit knows two basic data types -- integer and FP.
Arithmetic follows four rules:
Rule 1: Within types, conversions are simple: calculate the result
in the widest type of any input and convert to fit the destination,
using the right-most bits as the result if the destination has a
narrower integer type or rounding if the destination is FP.
Rule 2: An integer source operand with an FP destination is
converted to FP, using the width of the destination type if all inputs
are integers, or using the widest FP type that appears among the input
operands; then apply rule 1.
Rule 3: A calculation with an integer destination but all-FP source
operands is performed as per rule 1 to produce an intermediate FP
result; this FP result is then rounded to an integer and converted as
per rule 1.
Rule 4: A calculation with an integer destination but both integer
and FP source operands is performed as per rule 2 to produce an
intermediate FP result using the widest type of any FP input; the
intermediate FP result is then rounded to an integer and converted to
fit the destination as per rule 1.
Note that these rules are applied element-wise and any intermediate
result is formed only in the vector pipeline -- intermediate results do
*not* consume space in the vector register file.

Other vector operations may have specific requirements, for example
attempting to use a FP source for an indexed vector memory operation
raises an exception; the index vector in that operation must have
integer element type.
In the "very rough draft" of a vector encoding that I sent to the list
(message-id <5951A69D...@gmail.com>
<URL:https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/5951A69D.1000602%40gmail.com>)
back in June, I proposed encoding VADD as a special case of VFMA, and
VFMA only allowed vector destinations in order to avoid such quagmires.
The only instruction I proposed with a scalar result was VSETVL (VGETVL
was a special case of VSETVL with rs1 == x0). That encoding uses one
32-bit major opcode and provides VFMA, VMUL, VADD, VSUB, VNEG, VCOPY,
vector predicate operations, vector control operations, vector memory
access, and 94 remaining encoding slots for fully-general three-operand
vector instructions. Looking back, since integer/floating point is now
determined by the element type of the vector register selected in the
instruction, vector memory access only needs one slot instead of two, so
95 general vector operation slots would be available in that encoding.
Each of those 95 slots can also be divided into up to eight subslots if
all inputs must be either scalar or vector, 32 subslots if only two
general operands are required, or up to 256 subslots for two-operand
instructions where each operand must be either scalar or vector.

The only problem I see with it is that VFMA and derived operations
cannot mix integer and FP scalars, and integer/FP mode (which scalar
register file to use) for VFMA is not part of the instruction. Then
again, selecting between integer and FP scalar register files is
mode-like and a good candidate for CSR fields, either one bit
(all-integer/all-FP) or three bits (one per input operand; the register
file for a scalar destination is determined by the vector
element-type). This approach would help to minimize the amount of work
that the scalar unit must do when handling vector operations; the scalar
unit simply reads the indicated source registers (from the register file
indicated in the CSR fields) and adds those values, along with the
vector instruction itself, to the vector unit's instruction queue. This
is one reason I proposed a loosely-coupled execution model, somewhere
between the typical synchronous SIMD instructions and Hwacha's
completely decoupled vector-fetch model.

Generally, I believe that vector operations with scalar destinations are
unlikely to be useful, aside from special operations like
vector-get-element (which returns one element from a vector),
vector-process-carry (which uses a scalar register to hold a chaining
value) and similar. Instructions like these can probably fit in some of
the 30 remaining slots in the V3-S region in my proposed encoding,
avoiding the need for the scalar unit to further process instructions in VO.


-- Jacob

Sorry about that; I read your request after writing my most recent
reply. I will change the subject for my next reply if that discussion
comes back to me still on this thread.

-- Jacob