Hello again Nick,

So I'm splitting the changes in 3-4,... perhaps 5 patches, since
adding proper testing takes quite a bit of space and files. It might
look something along the lines of:
- Basic CPU/arch support, make binutils aware of the target.
- Basic VFPU (COP2) support for common DPU instructions (includes
instructions, registers, immediates, etc).
- Memory VFPU instructions and offset relocs.
- Support for "instruction prefixes"
- Perhaps some config files for easy configuration.

So far I'm attaching the first patch so that you can give me some
feedback. I'd rather get feedback early to know what I'm doing wrong
:)

The patch just adds the architecture "allegrex" as a MIPS II CPU. It
configures it with the extra instructions that allegrex features (many
from MIPS32r2), drops some non-existant instructions like COP2/COP3,
and adds the target to the testsuite with some extra tests for it. The
CPU is similar to the R5900 in the sense that it only supports 32 bit
FP support (all other MIPS CPU seem to either support both 32/64 FP or
none at all). I'm a bit confused on how the R5900 handles some of it
(I'd assume that msingle-float would be mandatory if
march=r5900/allegrex is used) since it produces binaries that are
marked as "FP ABI: Hard float (double precision)" which feels wrong to
me. Same goes for mfp32/mfpxx/mfp64 flags (seems like mfpxx should
always assume 32 bits for this platforms?).

Anyway, here it goes. Hope I pressed the correct buttons!

David

El mié, 16 nov 2022 a las 12:07, Nick Clifton (<nickc@redhat.com>) escribió:
>
> Hi David,
>
> > Although I have some idea on how I will create patches, I still have
> > some questions. Do you guys have some docs and guidelines on how
> > patches for new targets should look like?
>
> Not yet, but I am working on it.  I have created a wiki for the GNU binutils
> (https://sourceware.org/binutils/wiki/HomePage) with the intention of adding
> information suit able for users and contributors to the binutils.  It is a
> work in progress at the moment, but I hope that it will prove to be useful
> in the long run.
>
> > Any preferences or guidelines to make reviews easy for you?
>
> Off the top of my head ....
>
>    * One patch per problem please, unless the patch is very big,
>      in which case splitting it up based on top-level directory
>      is usually the way to go.
>
>    * Attached or inline patches are OK, although some people's
>      mailers do tend to corrupt inline patches (by line wrapping
>      them for example) so often attachments are better.
>
>    * Use git to create the patches (or "diff -rup if the sources
>      are not in a clone of the repository).
>
>    * Include details of how you tested the patch.  If possible
>      test with several different builds, in order to catch potential
>      problems.  For example if you are sub,itting a PSP patch which
>      also touches some generic files then testing with a toolchain
>      configured for a ntive linux host would be a good idea.
>
>
> > Perhaps there's some canonical examples you can point me to?
>
> Check the binutils mailing list.  It is full of them. :-)
>
> Cheers
>    Nick
>
>