[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 #79 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to dmitry.selyutin from comment #77)
> Added the array of entries itself, also pushed minor cleanup and fixup.
> Hopefully we can now proceed to merging entries as Luke described. One note,
> though: I was wrong, PPC tables are _not_ sorted by names, but instead are
> sorted by opcodes:

mmm that's a bit of a pig, then.

> include/opcode/ppc.h
> /* The table itself is sorted by major opcode number, and is otherwise
>    in the order in which the disassembler should consider
>    instructions.  */
> 
> Given that we have not that many entries, I think we might simply iterate
> over all SVP64 entries and lookup all PPC entries which match upon start

yeah, either that, or use the ppc64 lookup function *after* the hashtable
is created, and just go over the svp64 list in linear order.

> (e.g. when we meet "add" SVP64 entry, we'll try addo, add., addo. as well.
> Luke, does it look OK to you?

yyep, should work great.

(In reply to dmitry.selyutin from comment #78)
> You might use SILENCELOG=true python3 src/openpower/sv/sv_binutils.py
> ppc-opc-svp64.c to see the output. I'll think about "simply let 'em feed the
> goddamn directory path" approach as well, for now it's simpler to operate
> with explicit files.

> For now the output contains opcodes as well; I know we
> intend to drop these, but perhaps they might be good for some checks we do
> cross PPC opcodes.

extra effort. all mnemonics should be unique.  hey if it's in it's effort
to take it out.

now, about this:

struct svp64_entry {
    const char *name;
    struct svp64_opcode opcode;
    uint64_t in1 : 3;
    uint64_t in2 : 5;
    uint64_t in3 : 3;
    uint64_t out : 3;
    uint64_t out2 : 3;
    uint64_t cr_in : 4;
    uint64_t cr_out : 3;
    uint64_t sv_ptype : 2;
    uint64_t sv_etype : 2;
    uint64_t sv_in1 : 3;
    uint64_t sv_in2 : 3;
    uint64_t sv_in3 : 3;
    uint64_t sv_out : 3;
    uint64_t sv_out2 : 3;
    uint64_t sv_cr_in : 3;
    uint64_t sv_cr_out : 3;
    uint64_t : 15;
};

that's not going to work.  that's a massive... 1k entry where a 64-bit one will
do.

i was expecting this:

struct svp64_entry {
    const char *name;
    uint64_t svp64_info;
}

followed by some (perhaps auto-generated) macros:

#define SET_SV_IN1(val) ((val&0x3)<<5)
#define GET_SV_IN1(val) ((val&0x3)>>5)

where the settings in the c file comprise:

    svp64_info = SET_SV_IN1(someconst) | SET_SV_IN2(anotherconst) ....


something like that.

the code inside binutils would then use the GET_SV_XXXX macros to
obtain the required information.

using bit-fields in structs is non-portable and it won't make it
past review by the binutils developers.

also, the fact that there would be ten THOUSAND such 1k entries,
(because of 25 64-bit ints) that's far too much memory wasted.

whereas - as i said in several of the comments - a single uint64_t
is perfectly sufficient. adding up the total number of bits above
comes to 60 bits, which is less than 64.

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