[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 #25 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to dmitry.selyutin from comment #23)
> (In reply to Luke Kenneth Casson Leighton from comment #20)
> >   35 struct powerpc_opcode
> >   36 {
> >   63   unsigned char operands[8];
> >        svp64_opcode_table* svp64;
> >   64 };
> 
> Did you mean a standalone table, 

YES.  one that is autogenerated by sv_analysis.py.  do not even
remotely consider creating it by hand, this will be absolutely
disastrous.

> or you'd like to bound each and every Power
> ISA instruction to its own SVP64 table?

the SVP64_table to powerpc_opcode table is a many-to-one relationship.
it is not a many-to-many.

it would be absolutely distastrous to try to modify powerpc_opcode
by hand (10,000 instructions).

therefore:

1) autogenerate svp64_opcode_table
2) in ppc_setup_opcodes hunt through powerpc_opcodes looking
   for name matches powerpc_opcode->name == svp64_opcode

oh i see, yes:

a) call it "struct svp64_opcode_augmentation" (or something)
b) autogenerate a table named svp64_table[135] (whatever)
c) add a pointer to the struct svp64_opcode_augmentation

35 struct powerpc_opcode
36 {
63   unsigned char operands[8];
     struct svp64_opcode_augmentation* svp64;
64 };


> It really looks like that you meant
> to add plus one opcodes[]/num_opcodes pair, but the structure layout you
> posted tells otherwise.

yes name of table not name of struct.

> I'd really start with checking for "sv." prefix in mnemonics, and then
> splitting by space or slash. I, however, do not yet understand how SVP64
> works; it'd be nice to have some examples like "extsw from vanilla Power ISA
> vs sv.extsw 5, 3 vs sv.extsw. vs sv.extsw./satu/sz/dz/sm=r3/dm=r3 5, 31" and
> so on.

ironically - interestingly - understanding svp64 is not actually necessary
in order to translate it!  the job is that simple and self-contained.

a higher priority item is, funnily enough, to add the *32 bit* Draft opcodes
such as the FFT and DCT butterfly muladd, and the new ternlogi, all of
which need to go under a binutils --experimental-svp64 option (something
like that)

those can be done under a separate bugreport, btw.

SVP64 overview including FOSDEM video is here:
https://libre-soc.org/openpower/sv/overview/

bear in mind, there really is nothing actually useful or
relevant to this task, in there.  if working on the *simulator*
however, that would be a different matter: it would be absolutely
essential to understand SVP64.

however the data format, that is in links you will already find in
earlier comments, as well as in svp64.py etc which you should consider
to be the canonical reference guide.

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