Although it's somehow uneasy to see Linux propaganda there, I think the following document is a good reading. The section 3 is pretty valuable to know the year 2004 technologies. Through http://www.pmc-sierra.com/pressRoom/whitePapers.html Pick "Why You Should Use MIPS Processors?" Toru Nishimura/ALKYL Technology
On Wed, Jun 02, 2004 at 12:45:24PM +0900, Toru Nishimura wrote: > Although it's somehow uneasy to see Linux propaganda there, > I think the following document is a good reading. The section 3 is > pretty valuable to know the year 2004 technologies. > > Through > http://www.pmc-sierra.com/pressRoom/whitePapers.html > Pick > "Why You Should Use MIPS Processors?" I was under the impression that the current (3.x.x) GCC compiler doesn't produce very good code for MIPS processors. am I mistaken? -- -- Aaron J. Grier | "Not your ordinary poofy goof." | agrier <at> poofygoof.com "someday the industry will have throbbing frontal lobes and will be able to write provably correct software. also, I want a pony." -- Zach Brown
On Fri, 2004-06-04 at 16:13, Aaron J. Grier wrote: > On Wed, Jun 02, 2004 at 12:45:24PM +0900, Toru Nishimura wrote: > > Although it's somehow uneasy to see Linux propaganda there, > > I think the following document is a good reading. The section 3 is > > pretty valuable to know the year 2004 technologies. > > > > Through > > http://www.pmc-sierra.com/pressRoom/whitePapers.html > > Pick > > "Why You Should Use MIPS Processors?" > > I was under the impression that the current (3.x.x) GCC compiler doesn't > produce very good code for MIPS processors. am I mistaken? Um. 3.4 produces _very_ good code for mips processors. It's about 20-30% above the previous release. -eric -- -- Eric Christopher <echristo <at> redhat.com>
Aaron J. Grier wrote: > > I was under the impression that the current (3.x.x) GCC compiler doesn't > produce very good code for MIPS processors. am I mistaken? > The 3.x.x compilers produce code optimized more for speed than for size like 2.95 did. Also, all 3.2.x version of GCC have bugs related to usage of the '-fschedule-insns' in conjunction with '-O2'. -Steve
On Fri, Jun 04, 2004 at 11:50:23PM -0700, Eric Christopher wrote: > > > http://www.pmc-sierra.com/pressRoom/whitePapers.html > Um. 3.4 produces _very_ good code for mips processors. It's about > 20-30% above the previous release. I found a page in the above report about five minutes after I posted which mentioned some super MIPS optimizations had made their way back to the GCC 3.4.x branch. -- -- Aaron J. Grier | "Not your ordinary poofy goof." | agrier <at> poofygoof.com "someday the industry will have throbbing frontal lobes and will be able to write provably correct software. also, I want a pony." -- Zach Brown
On Fri, May 28, 2004 at 03:02:45PM +0200, Christophe Prevotaux wrote: > Is anyone porting netbsd to the WRT54G from LinkSys ? > > -- > =============================================================== > Christophe Prevotaux Email: c.prevotaux <at> hexanet.fr > HEXANET SARL URL: http://www.hexanet.fr/ > Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 > 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 > BP202 Fax: +33 (0)3 26 79 30 06 > 51686 Reims Cedex 2 > FRANCE HEXANET Network Operation Center > =============================================================== > I read somewhere it's possible. But I'm not sure it's been done already. Those low-cost boxes would make wonderful stuff to tweak into firewall, router... Nicolas.
All, As the release date for 2.0 nears, I've started to become a bit nervous about the state of MIPS support in the 2.0 branch -- specifically, the csh/sshd panics. Appended is a diff that backs out the specific commit that broke MIPS. It's a bit of a hack, as the working sigreturn was subsequently wrapped in a COMPAT_16 ... as such, 2.0 kernels will need COMPAT_16. I have tested this on my Indigo. I'd appreciate feedback from users of other platforms -- I have placed a sgimips-specific snapshot at http://www.rezrov.net/netbsd/sgimips-2.0 so that others can easily test this. If there are no valid objections within the next 48 hours, I'll submit the patch (and a patch that adds comments to arch/*mips/conf/* explaining why COMPAT_16 is necessary) to releng for immediate pullup to 2.0. Thanks, -- Chris GPG key FEB9DE7F (91AF 4534 4529 4BCC 31A5 938E 023E EEFB FEB9 DE7F) Index: lib/libc/arch/mips/gen/Makefile.inc =================================================================== RCS file: /cvsroot/src/lib/libc/arch/mips/gen/Makefile.inc,v retrieving revision 1.24 diff -u -r1.24 Makefile.inc --- lib/libc/arch/mips/gen/Makefile.inc 23 Mar 2004 12:31:52 -0000 1.24 +++ lib/libc/arch/mips/gen/Makefile.inc 13 Jun 2004 10:23:44 -0000(Continue reading)
On Sun, Jun 13, 2004 at 09:35:12PM +0900, Christopher SEKIYA wrote: > If there are no valid objections within the next 48 hours, I'll submit the > patch (and a patch that adds comments to arch/*mips/conf/* explaining why > COMPAT_16 is necessary) to releng for immediate pullup to 2.0. I'd just like to note that getting rid of the __sigreturn14 was a prerequisite set by core for the 2.0 release. Martin
On Mon, Jun 14, 2004 at 01:01:23AM +0200, Martin Husemann wrote: > I'd just like to note that getting rid of the __sigreturn14 was a > prerequisite set by core for the 2.0 release. Understood. However, the fact of the matter remains that doing so broke every supported MIPS platform. It doesn't appear that this will be fixed "properly" in time for the release. Given the choice between shipping 2.0 without support for an entire family of processors that was previously working, or shipping with a workaround ... -- Chris GPG key FEB9DE7F (91AF 4534 4529 4BCC 31A5 938E 023E EEFB FEB9 DE7F)
In article <20040613230122.GA5949 <at> drowsy.duskware.de>, Martin Husemann <martin <at> duskware.de> wrote: >On Sun, Jun 13, 2004 at 09:35:12PM +0900, Christopher SEKIYA wrote: >> If there are no valid objections within the next 48 hours, I'll submit the >> patch (and a patch that adds comments to arch/*mips/conf/* explaining why >> COMPAT_16 is necessary) to releng for immediate pullup to 2.0. > >I'd just like to note that getting rid of the __sigreturn14 was a >prerequisite set by core for the 2.0 release. In addition, this "solution" just hides the real bug, which will show up again once you start using setcontext(). christos
RSS Feed2 | |
|---|---|
3 | |
4 | |
2 | |
3 | |
6 | |
4 | |
13 | |
2 | |
8 | |
1 | |
2 | |
1 | |
3 | |
2 | |
30 | |
1 | |
7 | |
9 | |
11 | |
11 | |
14 | |
10 | |
5 | |
8 | |
3 | |
1 | |
42 | |
13 | |
4 | |
7 | |
4 | |
17 | |
17 | |
7 | |
1 | |
6 | |
16 | |
22 | |
9 | |
5 | |
6 | |
32 | |
2 | |
2 | |
9 | |
3 | |
5 | |
2 | |
3 | |
1 | |
9 | |
5 | |
2 | |
3 | |
23 | |
5 | |
1 | |
10 | |
23 | |
10 | |
31 | |
39 | |
6 | |
5 | |
9 | |
7 | |
7 | |
1 | |
41 | |
36 | |
10 | |
24 | |
12 | |
4 | |
23 | |
8 | |
28 | |
24 | |
66 | |
48 | |
24 | |
4 | |
2 | |
3 | |
3 | |
7 | |
79 | |
36 | |
5 | |
6 | |
23 | |
2 | |
20 | |
15 | |
8 | |
16 | |
37 | |
22 | |
44 | |
18 | |
5 | |
39 | |
13 | |
70 | |
26 | |
7 | |
1 | |
10 | |
15 | |
25 | |
2 | |
8 | |
10 | |
5 |
