[Libre-soc-dev] Attempt to run baselines: error
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon May 24 17:40:10 BST 2021
Lauri this ends happily with some "stuff" at this address:
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
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
@@ -33,4 +33,5 @@ wget:
- # 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
index 89b3cfa..88e9c7e 100644
@@ -312,6 +312,7 @@ ff_mpadsp_apply_window_float:
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>
> 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)
>> 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.
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
More information about the Libre-soc-dev