[Libre-soc-dev] Attempt to run baselines: error

[Luke Kenneth Casson Leighton]

Lauri this ends happily with some "stuff" at this address:

0000000000400040: 8000000080000000
0000000000400048: 8000000080000000
0000000000400050: 8000000080000000
0000000000400058: 8000000080000000
0000000000400060: 8000000080000000
0000000000400068: 8000000080000000
0000000000400070: 8000000080000000
0000000000400078: 8000000080000000

which i can only imagine, given that GPR 6 is set to 0x400000,
is somewhat reasonable / expected.

note i added "attn" at the end of the blr.  i'll commit the Makefile but
i'll leave the assembly code to you?

also, we could, hmmm, probably do with running this exact
same test under qemu, at this early point, to get a comparative
memdump / GPR / FPR dump.  otherwise there could be subtle
errors creeping in.

unless you have unit tests (running the code compiled as
its actual original c?) where we can take a look at the
expected results?

compiling the original c as a reference even on x86 would
likely be good enough, what do you think?  (running
under qemu is flakey.  doable, but the machine-interface
socket occasionally goes walkies).


lkcl at fizzy:~/src/libresoc/openpower-isa/src$ git diff
diff --git a/media/Makefile b/media/Makefile
index 51efe2a..dc23355 100644
--- a/media/Makefile
+++ b/media/Makefile
@@ -33,4 +33,5 @@ wget:

 tests: $(OBJ)
        echo juuh
-       # TODO pypowersim -i testname.bin
+       pypowersim -g audio/mp3/mp3_0.gpr \
+                -i audio/mp3/mp3_0_apply_window_float.bin
diff --git a/media/audio/mp3/mp3_0_apply_window_float.s
b/media/audio/mp3/mp3_0_apply_window_float.s
index 89b3cfa..88e9c7e 100644
--- a/media/audio/mp3/mp3_0_apply_window_float.s
+++ b/media/audio/mp3/mp3_0_apply_window_float.s
@@ -312,6 +312,7 @@ ff_mpadsp_apply_window_float:
        lfd 29,-24(1)
        lfd 30,-16(1)
        lfd 31,-8(1)
+    attn
        blr
        .p2align 4,,15
 .L10:

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Mon, May 24, 2021 at 5:10 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

>
>
> On Monday, May 24, 2021, Lauri Kasanen <cand at gmx.com> wrote:
>
>>
>> > - it's unclear why the log calls blr bclr, makes it harder to grep
>
>
> because blr is a pseudo-assembler shortcut for the underlying instruction.
>
> or, at least, it better damn well be.
>
>
>> > - it seems to pass memcpy successfully
>> > - there's a few unaligned exceptions, pretty sure it's well off tracks
>> > by then
>
>
> maybe not.  are there actual misaligned memory LD/STs in the original? 64
> bit LDs crossing two 64 bit words?
>
> the simulator's memory access is quite unsophisticated at the moment.
>
>
>>
>> It appears to freak out on the main function's return, the last blr.
>
>
> i would expect this, if lr on the stack has not been set up correctly to
> point to somewhere which ends up executing an "attn" (halt)
>
>
>> I
>> guess that would need special handling in the simulator, when all
>> existing tests presumably just end.
>
>
>  replace the last blr with "halt" (attn instruction)
>
> this is just a difference between bare metal and elf POSIX binaries
>
> normally the OS would have set up the LR for the application to jump back
> to, some code which ends the process etc etc etc.
>
> l.
>
>
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>