'ello,

On Fri 14 Feb, Chris Gilbert wrote:
> 
> On Fri, 14 Feb 1997, Marc Theisen wrote:

(Cache cleaning)
This and quite a lot of the pmap code needs to be, and will be, rewritten in
time. A speed up of several times will be the result. Timescales are not yet
finalised for this, but it won't be ``years.''

> > 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.

Another thing here is time time taken to load huge binaries from the disc (in
the first instance) due to the lack of shared libraries (see below).

> > 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)

IO bandwidth is a big factor (on things like cp) as well, of course. Cache
flushing will come into things a bit when doing gunzip etc. but is less of an
issue.

> > 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.

Again, this will be coming (hang on ;-) ).

> > 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?)

Presumably, you mean the MD part of the kernel. Assembler with C is sort-of
APCSish. For simple routines like strlen() or something like that you can
assume the arguments go in the same place as with APCS. FP arguments are
passed in integer registers in the same way as RiscOS. Obviously things like
the stack limit aren't needed, as the stack is paged in on demand; there are
a couple of other differences that I ought to remember but have forgotten.
You'll be able to work out the technicalities by looking at Mark's code.

> I'm willing to help, and have a good idea of how unix works (having just
> done a course last term on OS's)

	Cheers,

	Neil

-- 
* Neil A Carson (Carson@rmcs.cranfield.ac.uk)
* The Royal Military College of Science, Shrivenham.
* Address: Kitchener Mess, Royal Military College of Science, Shrivenham,
*          Swindon, Wilts SN8 8LA. Telephone: +44 (0)370 593183