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

[lkcl]

On Thu, Oct 11, 2018 at 10:12 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Thu, Oct 11, 2018 at 1:49 AM lkcl <lkcl at libre-riscv.org> wrote:
>
> > all of those never produce the word "FAILED" for all x in range 0-255
> > for all y in range 0-255 for all operands plus, minus, mul, div,
> > remainder (modulo), shiftleft and shiftright.
> >
>
> In
> https://git.libre-riscv.org/?p=riscv-isa-sim.git;a=blob;f=operators/operators.t.cc;h=b5ac0185adba82ad8424401a50807f63ecb383ea;hb=c3d43aa1e221c74936adac7673f1923cbec5fdd0
> You definitely need to check the assembly output as the first time it hits
> the divide op it has a divide by zero (y == 0), so the compiler could be
> optimizing everything out assuming it's unreachable. Try compiling with
> "-fsanitize=undefined", that should tell you when you do something that the
> compiler assumes doesn't happen.
>
> >  can you see anything wrong with the test code, that it might be
> > producing the wrong answers at line 19?
> >
> Divide by zero among other things.

 i need to change to a templated function and call this (or equivalent):

 require_extension('M');
sreg_t lhs = sext_xlen(RS1);
sreg_t rhs = sext_xlen(RS2);
if(rhs == 0)
  WRITE_RD(UINT64_MAX);
else if(lhs == INT64_MIN && rhs == -1)
  WRITE_RD(lhs);
else
  WRITE_RD(sext_xlen(lhs / rhs));


> Also, j is not initialized to anything.

 fixed that in an updated version

> >  appreciated... however taking that route would ultimately mean having
> > an external call-out from spike (c++) to a rust math library, as the
> > code, once tested (in rust) would then need to be used... in spike.
> >
> I didn't mean to use Rust in spike, I meant you could use Rust to check if
> different operations were identical and then translate from rust back to C.

 ... which would still need checking in c, so i might as well do it in
straight c :)

> >
> >  unless completely rewriting a new simulator entirely from scratch in
> > rust.  at 16,000 lines of code i'm not keen on doing that, as it would
> > require abandoning the hugely-tested spike codebase.
> >
> That would be a lot of work.

 yeah :)