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