RE: Embedded MIPS/Linux Needs

["Jay Carlson" <nop@nop.com>]

Disclaimer: I'm just a hobbyist.

Kevin D. Kissell writes:

> Here at MIPS Technologies, we use Linux internally
> for design verification, experiments, benchmarking,
> etc., and as a consequence Carsten Langgaard and
> myself have both been active in this forum, and have
> tried to help the general Linux/MIPS community as
> best we can with the limited time that we can dedicate
> to the problem, in terms of suggested patches, bug
> fixes, cleanups, integration of needed components
> like the FPU emulator, etc.

Yes, and this is quite useful!

> I have a question for those of you who are doing
> Linux work for *new* platforms (as opposed to the
> SGI/DEC legacy box support people).  IF, and I
> emphasize the word *if*, MIPS Technologies were
> make a bigger investment in MIPS/Linux technology,
> be it kernel enhancements, cross/native tools,
> userland ports, libraries, or whatever, what would
> be your prioritized "wish list"?

Some of these things can reasonably be done by third parties.  For instance,
mvista's in the business of nailing down particular toolchain versions and
doing relevant ports.  These days I'm mostly userland, so I get to assume
that working kernels are and will continue to be emitted from the smart
people on this list too :-)

My pet issue is code density and compiler quality.  I think it's in MIPS's
best interest to provide a really good compiler for their products, and I
think gcc does a good job for traditional embedded MIPS systems.  But the
gcc/gas-generated code for the SVR4 ABI is pretty bad, especially for the
low-end devices.  snow (see previous message) shows how much room for
improvement there is.

Individual embedded Linux companies don't have much motivation to attack
this problem alone, as it looks like it could involve extensive gcc hacking.
If a particular customer looks like they have code density issues, it'd be
easier for embedded linux companies to just recommend, say, ARM.  MIPS
Technologies on the other hand carries the banner for all devices licensing
their architecture, and any toolchain work may result in greater demand for
their own cores and licensee products.

ARM and Cygnus recently contributed a gcc ARM backend rewrite.  That's what
got me thinking about this.

Jay