[Libre-soc-bugs] [Bug 550] binutils support needed for svp64

[bugzilla-daemon at libre-soc.org]

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

--- Comment #67 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to dmitry.selyutin from comment #66)
> (In reply to Luke Kenneth Casson Leighton from comment #65)
> > therefore there should be no struct entries per se - just a list
> > of #defined entries, followed by ORing them together, and a matching
> > set of macros to extract the required information.
> 
> Please explain then, how do you expect to bind these on a per-instruction
> basis. Let's start with some instruction from some CSV. I compressed the
> bits into a single uint64 (bitfields) inside struct svp64_entry.

brilliant, that's great.  btw do disregard what i said about one file,
i realised late last night that two are needed: one for defines, one for
the list. took me a while, sorry, too much thinking in python :)

there should not be a list of 10,000 entries like in binutils,
that would be insane and also tie the codegenerator to the state
of binutils.

my thoughts here were to have an empty (0x0) value in the binutils
table (struct ppc_something) QTY 10,000 and, deep breath, when
creating the hashtable in binutils to at that
time *also* make a lookup for the corresponding
svp64 entry and fill in the empty field.

basically a manual implementation of a SQL database "LEFT JOIN"
(left, because some entries in the binutils hashtable will still
be 0x0 - NULL. a right join you would REMOVE the missing binutils
entry which is not what we want)

if both the 10000 binutils entries and the 200-or-so svp64 
entries are in strict alphabetical order then the LEFT JOIN
algorithm is O(N) because a lexicographic comparison can
simply increment each list index by one.

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