> You know I feel this is a lot unfair, espically on Mark.

I disagree. Mark has done a lot of work, which is good and impressive.
However, he has also left a lot of work unfinished and in a state where
others have not been able to complete it.

> I have never had any problems with any of my machines, be it a RiscPC,
> A7000, Acorn NC or Shark, getting NetBSD working and/or compiling. I know
> I didnt have SCSI based machines, or machines with anything but Ant
> ethernet cards (with the exception of the Shark),or strange set ups, but
> at one time I had a lot of machines running.

Nice for you, if true. Considering all the problems I have had,
especially connected with the buggy K S-ARM, and how other people
have complained, problems have been plenty and persistent.

> And appart from the startup time of Netscape 3.x/4.x on the RiscPC 700, I
> can never really say performance sucked (okay there were some issues with
> DEC on the compiler when we were doing shared libraries but even so that
> was one off initialization code)....

It seems to me that you have not seen how marvelously fast the StrongARM
can be when programmed properly. 

> And a dual processor P400 running a SMP kernel is going to out perform a
> 233Mhz SA110 on pretty much anything (with maybe the exception of hand
> written pipelined code that is designed to sit in the L1 cache of a
> single processor but how many of us have that).

My point is that they outperform NetBSD much more than they theoretically
should. They do not outperform well written code by me, compiled by
Acorn C/C++ that much.

> In terms of general 'integer' computing power however, I dont really
> think GCC or NetBSD/arm32 or anything is that bad.

Oh, but it is. I wrote earlier an example of exactly how integer arithmetic
code was as bad as it could be considering the sequence of instructions.
I then resequenced the instructions to get approximately twice the speed.

It is very typical of this maillist that people make thoughtful and
realistic observations of problems, and how to fix them, and then get
ignored, even when supplying those fixes. A year later it all happens
again, with the same problems.

> Of course if you want me to go about the architectural inadequancies of
> the Celeron, feel free to email me personally or any of the non-i386
> mailing list (or hey even the i386 ones).

I know perfectly well about the architectural inadequacies of Celerons.
Nevertheless, they outperform StrongARM NetBSD with good margins.
Some of this is due to the suboptimalising GCC problems I have described
thoroughly earlier.

> As for the "barely working" nature of NetBSD/arm32, I can assure you that
> a lot of us do NOT feel that way, and those that might have, have worked
> long and hard to help fix it.

A lot of people have worked long and hard just messing around with
uncompilable and wrong source code. A lot of people have worked at
fixes wich have been ignored. I have personally messed with GCC in
NetBSD ARM32, without getting anywhere. However, doing the same in
Linux is much more straightforward.

> Sorry, 2 rant of the week over.

NetBSD ARM32 had a good potential, wich was not fulfilled, due to 
insufficiently available source code, etc.

People has left this project.

Kim0