[libre-riscv-dev] daily kan-ban update 09jun2020

[Luke Kenneth Casson Leighton]

On Tue, Jun 9, 2020 at 10:01 PM Cole Poirier <colepoirier at gmail.com> wrote:
>
> On Jun 9 2020, at 1:15 pm, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
>
> > with michael having added the qemu-execution thing, you should now
> > first be able to add a "twi" (or tdi) instruction unit test to that,
> > first.
>
> This is filling in the pseudo-code for the soc/decoder/isa/caller.py?

yeees... however the first thing to do is write the unit test.  then
you have a means by which the code in caller.py py will be... called.
without writing the unit test, you have no way to call that code,
therefore how can you know if what you write is correct?

> > this will allow you to check that the *simulator* is correct.
>
> How do I use qemu to verify that the simulator is correct?

well, first we recall that it was michael who added the code, under
the recent bugreport from monday.  so we do this:

$ git log > /tmp/f

then, we open up that file, and grep "Michael".   that shows this line:
commit 613b15043fc7302c8ad4495b6bff65063eb1c0e3
Author: Michael Nolan <mtnolan2640 at gmail.com>
Date:   Mon Jun 8 13:36:57 2020 -0400

    Restore test_sim.py, begin modifying it for testing against qemu

that looks about right, doesn't it?  (i don't know the answer, either,
however i am simply following a deductive reasoning trail, from
evidence left by michael).

so let's do a git diff

$ git diff 613b15 3a0b0f

and that shows (just as the comment says) a file called test_sim.py.
from the top of the diff it shows that that test_sim.py file is in
soc/simulator/test_sim.py

so now we know where that file is.

> Sorry I've
> looked on the bug report and the wiki? Is there a wiki page with the
> procedure? If not, what's the procedure I should follow?

you need to think through a process of deducing this information for yourself.

looking at that file, it's a unit test, isn't it?  and it has the
exact same "run_tst_program" pattern that's in the test_pipe_caller.py
programs, doesn't it?

therefore, logically, if we put instructions in a unit test listing,
we expect them to be run, yes?

and if you look at test_sim.py's "run_tst_program()" function, we can
see that it has two aspects: the first being that the simulator's
"run_tst" function is called, and the second that the qemu
run_program() function is called.

each of those will modify their respective register files, and
qemu_register_compare walks through them and compares them, doesn't
it?

this really isn't hard to deduce!

therefore to test twi, we add a new unit test to that file, and run
it.  now, it *may* fail (because it's a trap, and we don't actually
know how qemu will react to that).  we'll cross that bridge when we
come to it, ok?  we expect at least the PC to be changed to 0x700, so
will have to work out how to get the PC out of qemu.


in essence, here, there is a series - a chain - of logical deductive
reasoning that allows us, from a few well-known sources that we have
access to, to find the information that was sought.

being able to do this, regardless of the size of the codebase and
regardless of whether quotes documentation quotes exists, is an
absolutely essential and critically important skill.

it is however important that you appreciate and have confidence that
you *can* in fact deploy such techniques (or others like it) in order
to find what you seek.

when this particular technique has failed me (due to the codebase size
being over a quarter of a million lines) i have been known to print it
out entirely on double-sided double-column pages (where an 80 char
limit has been absolutely essential in meeting that), and literally
going through absolutely every single page in the course of a day,
speed-reading flicking one by one, to get a "subconscious" handle on
the codebase that then allows me to go "i've seen that before" and
stand a chance of being able to find it relatively quickly.

l.