[libre-riscv-dev] spike-sv non-default element widths

[lkcl]

On Sun, Oct 21, 2018 at 8:53 PM Jacob Lifshay <programmerjake at gmail.com> wrote:

> On Sun, Oct 21, 2018, 09:42 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:

> > immediate operands are 12-bit and sign-extended.  so let's say rs1 =
> > 8-bit.  the algorithm says, effectively, that only 12-bit add need be
> > carried out.  obviously that's not going to work where rs1 is 127
> > (0x7f) and the immediate is 0x3ff (2^12-1), the result will wrap.
> >
> I'd say that the immediate is truncated to the 8-bit size of rs1 and then
> splatted into a vector which is then added to rs1. If there is an overflow,
> it just wraps around just like addw does.

 ok.

> > i'm quite tempted to say that the spec be changed so that rd, if its
> > bitwidth is over-ridden, uniformly applies across the board: rd's
> > bitwidth applies to rs1 (i.e. rs1 shall be sign/zero-extended to rd's
> > bitwidth, rs2 likewise *and* 12-bit immediates likewise), however that
> > loses out on the important possibility of using the information from
> > rs1+rs2's bitwidths to create truncated results that are then
> > sign/zero-extended into a larger rd's bitwidth.
> >
> It just depends on if it's more important to cast after the add or before
> the add. I recommend having it be sign/zero-extended before the add as an
> explicit cast instruction can be used if after-the-add is needed, whereas
> two are necessary if we use visa-versa.

 right.  ok.  so this is important.  bear in mind that there's ADD.W
(RV64I) and also ADD.D (Rv128I)

> > however there's also ADDI (separate and distinct from ADDIW), so some
> > of the possibilities are not being covered, i.e. i am concerned that,
> > according to the current draft spec, ADDI would end up being *exactly*
> > the same functionality as ADDIW, and likewise for ADDID.
> >
>
> The *w versions are needed to get 16-bit operations on rv64 and the *d
> versions are needed for 128-bit operations since there are 5 sizes
> supported (8, 16, 32, 64, 128), but 4 size settings in the csrs (8-bit,
> default/2, default, default*2).

 right, ok, so this is why i asked the question on clarifying how to
set XLEN from userspace, on isa-dev.  turns out it's done via UXL
which is in ustatus, which in turn requires the implementation to
actually support setting of ustatus (and spike doesn't, it only
supports setting mstatus and sstatus).

 jumping down to 8/16/32/64 i intended to be done by setting XLEN=32
(UXL), where, obviously, in doing so, that will restrict address-space
to 4GB as well, so care will definitely need to be taken: simply
avoiding the use of addressing-dependent opcodes may be sufficient.

 i.e. it's *not* done by using ADDIW / ADDW, or ADDID / ADDD from
RV64I and RV128I respectively, as one might intuitively expect.

hence why a bit of thought is needed.

l.