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

[Cole Poirier]

On Jun 9 2020, at 2:48 pm, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

> 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.

Thank you, I appreciate the walkthrough and the story about going the
old fashioned paper way. I thought that I had to do something in qemu
itself, which would have been outside the bounds of this deductive
reasoning process, as I have a tendency to get lost in forums and
documentation when dealing with complex, always buggy to some extent,
software like qemu. So I wanted to see if we had prior art pertaining to
qemu simulation. I think I should have taken the deductive reasoning
about the codebase approch for my other questions. I'm fighting my "aaah
I don't understand," and with your reminder and guide here will be able
to do so better next time.

> powerpc64-linux-gnu-gdb -interpreter=mi
> ~-data-list-register-names
> ^done,register-names=
>["r0","r1","r2","r3","r4","r5","r6","r7","r8","r9","r10","r11","r12","r13","r14","r15","r16","r17","r18","r19","r20","r21","r22","r23","r24","r25","r26","r27","r28","r29","r30","r31","f0","f1","f2","f3","f4","f5","f6","f7","f8","f9","f10","f11","f12","f13","f14","f15","f16","f17","f18","f19","f20","f21","f22","f23","f24","f25","f26","f27","f28","f29","f30","f31","pc","msr","cnd","lr","cnt","xer","fpscr","mq"

> ah HA!  one of those is the condition register!

Very cool and helpful. I think I over-stressed my self while working on
the presentation yesterday, which has caused me to inadvertantly 'take'
today off. Will be back and well rested to take on these challenges of
deductive reasoning, especially in using gtkwave to understand the ALU
signaling, tomorrow :)

Cole