[libre-riscv-dev] Updating the build script to run from any directory

[lkcl]

On Sun, Oct 28, 2018 at 1:07 AM Daniel Benusovich
<flyingmonkeys1996 at gmail.com> wrote:
>
> >
> > what would you like to do next?
> >
> > I have no idea what to do next! You mentioned working on:
>
>  the main immediate priority task is going to be unit tests, in
> > assembler, and writing macros (see
> > riscv-tests/isa/macros/simplev/sv_test_macros.h and anything starting
> > isa/rv*/sv*.c
> >
> >
> So I believe that would be worth doing if you have not done it yet.

 i'm using the unit tests to make sure that each piece of
functionality is at least reasonably going to work (and thus stay that
way during the various extremely complex multi-stage code-morphs),
however they're definitely incomplete.

 one example is: a test is needed which sets element widths to a matrix of:

 * 8 or 16 for destination
 * 8 or 16 for RS1
 * 8 or 16 for RS2

and the *operation* to be passed in as a parameter to the macro.  for
how that works, look at riscv-tests/isa/macros/scalar/test_macros.h
and chase through how TEST_RR_OP calls through to TEST_CASE.  the
actual instruction code is passed in as a parameter (!)

now, there's two possible variants here that are needed:

* a set of hard-coded tests, you can see some in both rv64ui/add.S
*and* in rv64ui/sv_addw_elwidth.S

* an actual massive "comprehensive overkill" series of nested
for-loops testing *ALL* combinations of 0-255 for destination when
destination's elwidth=8, and 0-65535 for when elwidth=16, and likewise
for RS1 *and* also RS2.   the answers to be checked by doing the
*exact* same thing on *SCALAR* registers, and comparing the *SCALAR*
answers to the parallelised ones.

 this latter is quite a bit of work, so working towards it rather than
doing it straight away is probably a good idea.

 so.

 i tell you what.

could you take a look at sv_addw_elwidth.S, and, at line 25 where you
see "addw", *replace* that with a macro parameter "code", just like in
the scalar test_macros.h (it's called "inst"):

#define TEST_RR_OP( testnum, inst, result, val1, val2 ) \
    TEST_CASE( testnum, x30, result, \
      li  x1, MASK_XLEN(val1); \
      li  x2, MASK_XLEN(val2); \
      inst x30, x1, x2; \
    )

then, also, add "testdata" as an input parameter to the macro (because
we need different test data).

then, move the (modified) SV_ELWIDTH_TEST macro into sv_test_macros.h

*then*, go back to sv_add_elwidth.S (not sv_addw_elwidth.S) and rework
it - replace it - to use the new SV_ELWIDTH_TEST macro.  which should
end up looking something like:

        SV_ELWIDTH_TEST(  0, 0, 0, add , testdata,
                0xffffffff8b6bab8b,  0xffffffff88684828,  0x0000000000000000 )

do this *really carefully*, quite literally one line, one thing, at a
time.  so, pass in "inst" as a new macro parameter, replace "addw"
with "inst", then run "make" followed by "rm *.out" followed by "make
run".

once you have confirmed that works, git commit it, email me the git
format-patch immediately (privately as an *attachment* if you prefer,
rather than use git-email), and move on to the next tiny bit.

if ever you make a mistake, the unit test will *not terminate
properly*.  you have to press ctrl-c twice.  at that point, note which
test it was, and run it *manually*, e.g. like this:

$ spike --isa=rv64gc rv64ui-p-sv_addw_elwidth >& g

press ctrl-c twice, then start looking through the output.  i've put
in absolutely loads of debug print statements, so as to be able to
track things down.

always always go from a position of "known working", making ONE and
ONLY ONE change, okay?

what you can then do is:

* from a working position, get some output (file g, above)
* add ONE LINE to the unit test (where you don't know if it's correct)
* run ANOTHER manual spike, output do a DIFFERENT FILE
* do a "diff -u" on the two files.

now you know precisely and exactly where things worked in each, and
where things failed.

as an example, try this, at like 47 of sv_addw_elwidth.S:

        SV_ELWIDTH_TEST(  1, 1, 1,
                0xa5a5a5a5a56bab8b,  0xa5a5a5a5a5a5a5a5,  0xa5a5a5a5a5a5a5a6 )

change that LAST parameter from ....a5a5a5a5 to ...a6a6a6a6, and do
the "diff" trick i mentioned, above, on the two outputs.

the diff will show you precisely where things go wrong, and you will
begin to get used to interpreting the debug output.

l.