This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: RFC: mips target support for Juniper Apollo
- From: Eric Christopher <echristo at redhat dot com>
- To: Jim Wilson <wilson at specifixinc dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 10 Mar 2004 00:57:11 -0800
- Subject: Re: RFC: mips target support for Juniper Apollo
- References: <1078905508.25545.99.camel@leaf.tuliptree.org>
> The Juniper Apollo is a bit of an oddball target. It is based on the
> r4000, but is a 32-bit part, so the only thing that really looks like
> the r4000 is the coprocessor 0 support. It adds a few instructions
> which are handled by this patch. It removed a few instructions which I
> haven't tried to handle here. I didn't see a mechanism for this.
>
It's not hard, but unfortunately is tedious. It should be done before
you add the port into binutils though. The tx39 is a good example - it's
a mips2 processor minus a few instructions. As you'll see we had to add
most of them by hand in there. It makes for annoyingly long diffs but...
> It is also missing branch delay slots. This is a serious
> incompatibility which requires having separate magic numbers for Apollo,
> as it won't be compatible with anything else.
Eek.
>
> I'm concerned about the choice of the magic numbers. I don't want to
> conflict with number that Red Hat is using, but only a Red Hat employee
> can check that. This primarily means E_MIPS_MACH_APOLLO in the
> include/elf/mips.h file.
>
Thanks for checking, but no, it doesn't conflict with anything we've
got.
> I am looking for comments, particularly from MIPS maintainers, as to
> whether the patch is reasonable, whether anything should be changed,
> etc.
It's ok with the addition of the mechanical job I mentioned above. I see
you turned off the branch delay slot optimizations and so that would
have been my only other worry.
-eric
--
Eric Christopher <echristo@redhat.com>