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

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue May 25 10:48:00 BST 2021

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


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

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


More information about the Libre-soc-dev mailing list