[Libre-soc-bugs] [Bug 982] Support PowerPC ABI in ISACaller

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=982

--- Comment #122 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Dmitry Selyutin from comment #120)
> (In reply to Luke Kenneth Casson Leighton from comment #119)
> > ok you notice how in comment #90 i did *not* pass in the "cheat"
> > argument? that was deliberate. it means that the straight rfid
> > pseudocode gets called, as-is.
> 
> It still is, even with passing syscall_emu_active parameter. :-) I just
> needed something to check to make asmop be the same as ins_name; otherwise
> the code thinks we met an illegal instruction.
> 
> illegal = ins_name != asmop

ah errr that shouldn't happen.  ohhh hang on yes i think i know what is
going on, the pc is pointing to 0xc00, of course there is no
instruction *at* 0xc00 so it gets a NULL op, which is "illegal",
and it all goes to shit from there.

so yes sigh "cheat" mode is necessary. sigh.  or we split out
ISACaller.call() into yet anoooother function. let me handle
that ok?


> IIRC I did it since both evaluate to OP_RFID.

OP_xxxx is only relevant for the HDL.  ISACaller uses the insndb
dictionary.  see all.py

the HDL does *further MANUAL explicit decoding* whenever an OP_xxxx
is shared like that.  OP_ADD is an extreme example, check the CSV
files, you will see there are something like *THIRTY* different
OP_ADD entries, all with completely different insndb parameters.


> > > https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;
> > > h=e25fca65a5a0faecdd9040689b5fe1f44b9a64a7
> > 
> > pass in "None" instead and do "if initial_msr is None:
> > initial_msr=0x9000000000001" (MSR.LE | MSR.SF)
> 
> You mean ISACaller.__init__, right?

*no*, under no circumstances change that. if you run all the
unit tests all hell will break loose.  when i said test_runner.py
(implicitly by replying to the commit-diff) i meant test_runner.py
and not anything else.


> So you mean that we actually got the correct value, it's just that my
> expectations were incorrect?

correct.

> > great! see comment #90 again (2nd from last paragraph).
> > set e.msr = 0xfbfffffefd7f10c5 and we are pretty much done.
> 
> I'm confused. Comment #90 is my comment... :-) You probably meant something
> else?

yes. comment #97. sorry. was on a train.

(In reply to Jacob Lifshay from comment #121)

> please use DEFAULT_MSR instead, since it includes the bits needed for fp to
> work, 

good call jacob. yes the whole default MSR thing really needs to
be a global setting at some point so that the entire test suite can
be run in BE mode. or 32-bit mode. but this is a frickin lot of work
and i still after 3 years cannot think of a good solution to that.

hmmm... now that i think about it, really jacob you should be using a
DEFAULT_MSR_FP to ensure that FP is *not* enabled by default *except*
for actual FP unit tests.

(i e. DEFAULT_MSR needs to be set to MSR.LE|MSR.SF)

-- 
You are receiving this mail because:
You are on the CC list for the bug.