[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 #68 from dmitry.selyutin at 3mdeb.com ---
(In reply to Luke Kenneth Casson Leighton from comment #67)
> 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 :)

OK, so we both agree that there must be at least _some_ array, even if this
array contains only uint64_t (I doubt, though: there must be at least something
which binds svp64 entry and ppc opcode, be it instruction name or opcode
itself).

> 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.

283 entries totally. :-)

> 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.

I thought of standalone hash but I think that's mostly implementation detail.

> 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.

PPC entries are alphabetically ordered, inevitably, so will be ours due to the
same rationale. :-) There's no comparison or sorting yet in Python, but yes,
this is needed. Again, not sure if we need to touch existing structures by
adding the pointer, I'd rather prefer a separate stuff to keep the code as
decoupled as possible.

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