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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat Jan 8 14:42:37 GMT 2022


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

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

More information about the libre-soc-bugs mailing list