[libre-riscv-dev] [Bug 269] auto-conversion / parser of POWER ISA Spec v3.0B
bugzilla-daemon at libre-riscv.org
bugzilla-daemon at libre-riscv.org
Sat Apr 4 20:38:42 BST 2020
http://bugs.libre-riscv.org/show_bug.cgi?id=269
--- Comment #18 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
urrrr okaaay...
i just added parser support for this:
MEM(EA, 4) <- GPR(r)[32:63]
which requires two nested depths of brackets:
GPR (r) level 1
GPR (r) [32:63] level 2
in the process, you can see i added a class Mem and also added
to the class GPR
https://git.libre-riscv.org/?p=soc.git;a=commitdiff;h=2ecec80b841136e052b6e7d39b76abaca77bb612
i don't know if you're familiar with __call__, michael: it allows
you to (literally) call an object as if it was a function.
so with gsc.gpr being an object of type GPR, rather than mess with
the parser any further i did two things:
1. assign a GPR instance into the dict d for the exec(), by key 'GPR'
2. add an __call__ to class GPR.
therefore, when the code sees 'GPR' - GPR(r) for example - it calls
GPR.__call__(5)
the return result from _that_ is then passed through a second level of
processing (a slice), and that gets assigned into Mem
an instance of Mem i *also* assigned into the dict d for the exec(),
by key 'MEM'.
this - again - through the Mem.__call__(addr, bytesize) trick - allows
*getting* memory.
however for setting i didn't want to overload dict because the key
is not just a single index (address), it's actually an address-bytesize
tuple:
MEM(EA, 2) <- RA
which, hmm, whilst that *could* be turned into this:
MEM[(EA,2)] <- RA
which would, if __setitem__ was overloaded, could allow for recognition
of the tuple, decoding it back into (addr, bytesize).
yuk, is my honest opinion :)
so instead, i "recognise" the pattern "MEM(addr, sz) <- x" back in the
parser "assignment" phase, and *REPLACE* it with this:
memassign(addr, sz, x)
which you'll see in... hmmm i'm moving class Mem into decoder/isa/caller.py
ok?
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-riscv-dev
mailing list