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
