[libre-riscv-dev] [Bug 269] auto-conversion / parser of POWER ISA Spec v3.0B

[bugzilla-daemon@libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=269

--- Comment #18 from Luke Kenneth Casson Leighton <lkcl@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.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev