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

[Luke Kenneth Casson Leighton]

On Tue, May 25, 2021 at 6:33 AM Lauri Kasanen <cand at gmx.com> wrote:

> On Mon, 24 May 2021 17:40:10 +0100
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
>
> > are there actual misaligned memory LD/STs in the original? 64
> > bit LDs crossing two 64 bit words?
>
> None.
>

ok - i suspect then that the last blr which jumped to location 0x0
(because LR=0 on entry) used corrupted values for function parameters
on a second call.


> > Lauri this ends happily with some "stuff" at this address:
>
> Probably, won't know if it's correct until we can both load and save
> data. Save after the run is still missing I believe.
>

load's there.  memory-dump's there.

     XER 0x0
     LR 0xffffffff
     CTR 0x0
Mem
0000000000003ec0: 0000000000003f20
0000000000003ee0: 0000000000100880
0000000000003ee8: 0000000000100080
0000000000003ef0: 0000000000100800
0000000000003ef8: 0000000000100000
0000000000003f00: ffffffffffffffff
...
0000000000004010: 00000000ffffffff
...
0000000000400040: 8000000080000000
0000000000400048: 8000000080000000
0000000000400050: 8000000080000000
0000000000400058: 8000000080000000
0000000000400060: 8000000080000000
0000000000400068: 8000000080000000
0000000000400070: 8000000080000000
0000000000400078: 8000000080000000

it can at least be visually inspected.  today's task: add save/dump.



> > note i added "attn" at the end of the blr.  i'll commit the Makefile but
> > i'll leave the assembly code to you?
>
> I would much prefer the simulator be changed. There may be multiple
> exits, early exits, etc. This allows the code to be proper, and
> reusable without changes in the later codec code.
>

hacking a "bare metal" simulator... i'm mentally resisting that one.
it would be much better to do a "proper" job of being able to run
ELF binaries, particularly given that much of the loading (etc.)
and commandline parameters (etc) are substitutes for what
ELF does anyway.

one step at a time.


> I propose: simulator sets LR to a magic constant on startup. blr checks
> for that to exit. 0xf4751f1ab73; (falsifiable) may be a good one, since
> it's both non-4 and non-2 aligned, as well as larger than 32-bit.
>

turns out that it already terminates as long as the PC is set to a
point outside of the range of the length of the listing.

by loading LR from an external SPR file there was no need to
change the code.

https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=382510a4cbdded64b6405f9ef45349be414e3afa

except to support loading by names of SPRs by string so that they're
readable.


> I don't have the qemu setup, but if you want, you can do so.
>

it's more work, so i'd prefer not to unless necessary.


> > unless you have unit tests (running the code compiled as
> > its actual original c?) where we can take a look at the
> > expected results?
>
> We do have those. Check the data dirs. There's standalone C and a set
> of data files that passes on x86.
>

ahh fantastic


> This being float, there's some chance x86 rounds different to ppc and
> there may be 1-bit differences, but that's to be determined.
>

well, luckily (for now) ISACaller is actually using x86 FP operations
underneath.  however these are done at 64-bit IEEE754 then
(if required) downconverted to FP32.  this *may* result in bit-errors
on certain operations, particularly divide / mul.

l.