[Libre-soc-bugs] [Bug 979] Implement C-based Power ISA decoder compiler

[bugzilla-daemon at libre-soc.org]

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

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
       The table of|# ghostmansd=
              |ghostmansd=5000
  payments (in EUR)|# lkcl=                     |lkcl=500
     for this task;|                            |
        TOML format|                            |

--- Comment #8 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Dmitry Selyutin from comment #5)
> OK, it looks like I have something already. Still working on that, but the
> result looks promising.

awesome, that was quick.

> As you can see, the overall code structure is somewhat familiar... :-) 

indeed, i suspect it will end up near-identical to binutils obj/asm
except perhaps with a stand-alone, more self-contained API?

btw watch out for the size of the decoder table, and consider
(as a *second* phase of optimisation) using that quine algorithm
https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/quine.py;hb=HEAD

it should then be easy to "group" by the largest number of
matching bits (by masked-value up to a maximum
set array size, then branch out in a tree:

opcode 0b--011111
opcode 0b---11110

results in a "first level" matcher of "0b---1111-".

the idea there being to reduce decode time by not having massive
numbers of if-elif-elif-elif conditions but instead a cascading
sequence of jump-tables. hell, even arrays of functions to call
that decode the next part.  anything to avoid the massive
switch/case mess.

i would expect this to create a three-level jump-table, corresponding
to MAJOR PO, then 1/2 of the XO (bits 26-31), and finally bits 21-25
although ironically you might as well do that by hand, sigh.

a fun option to explore would be hashes, but not just any hash:
*actually dynamically and randomly find one* that happens to
produce 100% unique hits (remember "illegal opcode" has to be
also detected)

and if you *really* want some fun, and to not have L1 Cache
end up being obliterated due to the size of decode being so large
it cannot fit in L1 Cache, look up "MROB RIES", which is a FORTH
engine, and adapt it to find an *equation* that produces a unique
index for each opcode (!!! yes really! i have seen this done with
UCS-2 to DOS Codepage tables, in samba)


but... all still way into the future as an optimisation.

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