On Fri, 14 Feb 1997, Marc Theisen wrote:

> Hi Freaks!
> 
> I am now "using" (which means installing and testing!) RiscBSD four
> about four weeks. I upgraded my SA-driven RiscPC with a Quantum Fireball
> TM 2.1GB and added 32MB DRAM. So RiscBSD seems to run fine in comparison
> to these old Sun's here at my University. But when I compare the system
> performance in some cases RiscBSD really needs to be improved, I think.

There are some areas which are being worked on, AFAIR some C lib routines
need to be improved, but the kernel can't do everything, they are giving
up his own free time to do this.  The most noticable problem is that the
Cache cleaning code for the SA is lacking at the moment, this was due to
the speed that the SA kernels were available, the first SA kernel was
on-line before mark had his SA!  This is where most of the time is
spent/wasted, in flushing the caches every virtual memeory thing (can't
remember the work) 

> Just look at Suse's Linux for IBM-PC's: After typing "xterm &" there is
> a delay of, well say just a half of a second and there it is! Under
> RiscBSD this procedure takes several seconds, with a SA and 40MB RAM! I
> also tested the performance by comparing the execution times of
> unzipping large files with gunzip. There the difference was much bigger
> and I think that the lack of a Math-Coproc is not a sensible reason for
> this. So I assume that there are a lot of routines in the kernel which
> can be improved, or am I wrong? 

Yes, the cache flushing ones.
 
> Okay, I am not experienced with UNIX-systems but with writing effective
> machine-code which has to run under RISC-OS. To shorten this message:
> 
> Could anybody summarize the procedures to build new kernels?

You need to download the sys source for the NetBSD tree, try
ftp.southern.com in /pub/NetBSD/src/tar_files, also the kernel config
guide is useful (but dated :()

> Do these simple utilities like 'cp' or 'gunzip' take advantage of these
> improved routines or do they have to be recompiled?

These routines won't speed up very much, this is due to all the cache
flushes when switching processes (a prime example is mkdep)

> Why does RiscBSD not take advantage of a kind of a "SharedCLibrary" like
> it is used under RISCOS?

RiscBSD can't do this yet, as it requires compiler support for Dynamically
linked libraries.

> (As I look at the code-size of the utilities above I understand why
> using RiscBSD needs upgrading your hardware...)
 
Again lack of linked libs from gcc, this means all the code has to be
linked into the binary file.

> Well, I would be happy if I could give a little of my knowledge to the
> porting team in order to make life easier using RiscBSD.

> So if there are some code sequences which need to be optimised using
> Assembler code, here I am! 

I've taken a look at some of the kernel code, and seen some areas for
improvement, but not sure where to start.  I think Mark has added
commenting to most of the areas I've looked at, and you can understand
what's going on.  The main problem that'd slow me down is lack of
knowledge of how asm is intergrated into C (does it use APCS?)
 
I'm willing to help, and have a good idea of how unix works (having just
done a course last term on OS's)

Chris Gilbert