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

[Jacob Lifshay]

On Sun, Oct 21, 2018 at 3:01 PM lkcl <lkcl at libre-riscv.org> wrote:

> 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)
>
I was treating it as

>
> > > 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 highly recommend using some method other than changing XLEN as that
changes the whole ABI used. LLVM does not support changing the ABI at that
level of resolution as it assumes it's constant for, if not the entire
program, at least for an entire module. I believe GCC is even more strict
about changing the ABI (I know that separate programs are usually necessary
for each architecture, where as LLVM can have them all built into one
program).

If we pick a different method (maybe expanding the width field by 1 bit and
using constant sizes instead of XLEN-dependent sizes) then we wouldn't have
the problem with needing to have vectors allocated in a certain portion of
the address space as that's usually a giant mess.

>
>  i.e. it's *not* done by using ADDIW / ADDW, or ADDID / ADDD from
> RV64I and RV128I respectively, as one might intuitively expect.
>
I do think using the w and d variants to determine the width would work as
the code being compiled would almost always specify the element width at
compile time and just have the element count be variable.

Jacob