RE: Broadcom XLP support

["Maciej W. Rozycki" <macro at imgtec dot com>]

On Wed, 3 Aug 2016, ANDY KENNEDY wrote:

> >  I think it's as much guidance I can give you for an external patch.  If
> > you want proper support (and E_MIPS_MACH_XLP fixed in the ABI), then I
> > suggest persuading Broadcom to submit their change properly for inclusion
> > with FSF sources.  I'll be happy to review it.
> 
> It was set to the same thing as INSN_OCTEON3.  I'm guessing that is not
> exactly desirable.

 Indeed it likely makes some matching logic fail.

> After changing it, however, I get the same thing.

 You may have to double-check the opcode table's `pinfo' flags too, as 
these have been redefined, although I think getting these wrong shouldn't 
really cause a fatal failure, even though the generated machine code might 
be wrong (these flags are used for delay slot scheduling and suchlike).

 Also I suggest experimenting with a small assembly source with all the 
new XLP instructions included and getting it to build successfully first, 
rather than getting through the pain of rebuilding the whole toolchain 
only to see it fail again.  A proper test case covering all the newly 
added or modified instructions should have been included with the original 
change (and will be a prerequisite for the acceptance of any future patch 
submitted).  It would make patch port verification easier, but since 
there's none, you'll have to make it yourself.

> The toolchain that Broadcom builds is a 20+ hour build.  We got it to build
> a couple of years ago, but due to the length of time required to build the
> sucker, we packaged up the resulting toolchain and wrapped a Makefile around
> it as to not have to build it again.

 With faster hardware available the build may have become shorter though.  
Also you should be able to rebuild binutils only if you need to, it's the 
easiest part.

> Otherwise, there are missing entries in various files in binutils -- missing
> from what the XLR has in it.  Since these are closely related, I should be
> able to figure out what to put where for the XLP in those missing locations.
> Doing that, nearly from scratch (using Khem Raj's patch), should grant me the
> copyright for the code, though IANAL...

 That might be questionable, I advise enquiring with FSF.  It might be 
easier if XLP instruction set documentation was available, but it's NDA'd 
I believe.  Granted, with that in hand and using XLR as a template it 
would be hard to come up with code substantially different from any 
previously proposed.

 FWIW,

  Maciej