[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 #75 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to dmitry.selyutin from comment #71)
> A question on matching the names: we have bunch of instructions named like
> "4/6=mtfsfi", "26/6=fmrgow", etc. 

not quite: the developers of microwatt placed the instruction name
into decode1.vhdl and decided in the case of FP instructions to
(consistently) subdivide the XO field into a pair of HI-LO numbers.


> In good ol' PPC, these have no prefixes, I
> assume SVP64 added them?

i don't follow the question, but the above may explain and make it moot.

> Should I simply discard everything before '=' sign
> to keep the name as it appears in binutils?

yes.  this is exactly what is already done in power_decoder.py (and in
the CSV-reading classes that you have already been using).

(In reply to dmitry.selyutin from comment #70)

> > errr oh yes, you're right: instruction name (as an ascii string) followed
> > by uint64_t.  doh.
> 
> It also looks like that at least a pair of two uint32_t is needed to
> represent opcode plus mask (cf. opcode in extra.csv).

ah no, definitely not.  the name of the instruction is the "unique key".
you *do not* need the opcode.  the *name* is unique and can be used as
the match.

(only thing is, you need to match "add." against "add")

> Ah, OK, I got the rationale. Well, for this particular case, we could've
> even searched entries in a sorted array, since count of entries is quite
> limited (cache-friendly 283 entries; makes even more sense to keep these
> compact). However, since we have to lookup PPC entry anyway, regardless of
> whether we deal with SVP64 or not, I think saving one lookup is totally
> reasonable. I'll need to consult you when I start doing this, since I've
> never used SQL, but I think I get the overall idea. Thanks for the tip!

something like this:

ppc_insns = [{name="addi", blahblah, svp64stuff=0x0},
             {name="addeo", blahblah, svp64stuff=0x0},
             {name="fredinsn", ....}
             ... ]
svp64_mods = [{name="addi", svp64stuff=0x991212121},
             ]

lex_idx_svp64 = 0
for i in range(len(ppc_insns)):
     ppc = ppc_insns[i]
     found_match = False
     while True:
         svp64 = svp64_mods[lex_idx_svp64]
         lexicographical_compare = cmp(ppc->name, svp64->name);
         if lexicographical_compare == 0:
             found_match = True
             break
         if match > 0: // no match, name is greater
             break
         if match < 0: // must "catch up" svp64 array
             lex_idx_svp64 += 1
             if lex_idx_svp64 == len(svp64_mods): // overflow!
                  break
          if found {
               // fill in the svp64 field in ppc_insns
               ppc->svp64stuff = svp64->svp64stuff

that's it.  that's a SQL "LEFT JOIN", and it works by assuming
that the primary key in each "table" is pre-sorted.

you can do it even inside the function that creates the hash lookup
as it is walking the 10,000-long ppc_insns 

you *do not* need the opcode/mask to do this.
to repeat: you *do not* need the opcode/mask.
the match is by *name*.

in python (SVP64 CSV-reading class) i do this merge using a dictionary, so
it is like... 2 lines of code.

the only tricky bit is that the "cmp" function must strip off any
"o", "." or "o." at the end before doing the compare. Rc=1 and OE=1
are the exact same instruction, so they have to match.

match:  ppc->name = "addo" svp64->name = "add" MATCHES
match:  ppc->name = "add." svp64->name = "add" MATCHES
match:  ppc->name = "addeo" svp64->name = "addi" FAILS (obviously,
         because it's a different instruction)

(In reply to dmitry.selyutin from comment #74)
> Wow, inheriting power_enums.py stuff was really a nice idea. With the recent
> updates from Jacob, I see stuff like `SVP64_IN2SEL_CONST_XBI` for free!

gooood.  that's a huge relief, because maintaining stuff by hand that
gets out of sync ==> bad idea.  nice decision.

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