Re: 060 problem with NetBSD (1.2 upwards)

[Ignatios Souvatzis <ignatios%theory.cs.uni-bonn.de@localhost>]

> Hello,
> 
> On 15-Sty-98, Ignatios Souvatzis wrote:
> 
> >Oh no....  How do you know it is CPU exceptions which slow down the
> machine?
> 
> Because it's the most likely cause of pointer jerkiness and general
> slowdown. And I didn't say "I know". I said "I guess".
> 
> >This might be the case for the 68060... (much less likely for the 68040;
> >only
> >slow former FPU operations like FSIN are emulated there) but you'd have to
> >prove it. (E.g.: run "systat v" in a xterm and watch for 060intemu and 
> >friends).
> 
> And so I did. On a clean system (no X) it reported about 30intemu (peak 50)
> and ~80fpuemu (all values per second). Then I started X (without wm, because
> I run Enlightement and it is quite heavy by itself). I was getting 50intemu
> (peak 80), no change with fpuemu. By just moving the mouse around I could
> easily increase intemu to about 250.

Just for comparison: 

68060 at 50 MHz does (on NetBSD-1.3):

- 220000/s MUL rx,ry:rz
- 170000/s DIV rx:ry,rz

so a few hundred total shouldn't bother you at all.

The NetBSD-1.2 values were about half of that (well, sshd did 110000
060intemu/s, and it should mostly need the multiplication.

Anybody who uses movep inside application programs deserves bad things to
happen. (Compilers I know of don't create it).

> 
> Then I started mosaic. For the first few seconds I was getting ~1000 (peak
> 1600) intemu, with still ~80fpuemu. But when the moment of pointer freeze
> came, fpuemu reached over 20000 for as long as four or five seconds. At this
> time intemu was around 120.

20000/s? that starts to be annoying, zes.
> 
> Now I am not surprised I had the same problems with both 040 and 060.
> 
> 
> >Yes. Problem is, that ssh uses hand-optimized for 68020-40 assembler stuff;
> >you can't change that with a compiler option.
> 
> I am pretty sure I can convince SSH to use the C-version of the routines.

even better: build the support routines for 68060 (using bitfield routines
but no 32/64bit stuff). They're the core or the gmp engine and deserve some
hand-coding.

> Considering the above results and the fact that 060 gets exceptions (albait
> not on mosaic's or ssh's scale) from almost every software (yep, even gcc is
> a trouble maker) what do you think about providing future distributions
> compiled with -m68060? Users of earlier CPUs will barely (if at all) feel
> the difference, but it will make NetBSD-Amiga a whole lot more usable on
> 060.

Oh yes, on the average, they will.
And its much easier for 060 users to recompile their libc, Mosaic, and gcc
than for 020 @ 20 MHz (yes, there are people out there using NetBSD not only
on small Amigas, but on small hp300 or sun3 machines).

Maybe we'll manage to have a completely common m68k userland for the next 
release... in this case, we can afford to have 68040 and 68060 versions of
libc and programs.

Btw: before you recompile stuff:

- use "systat p" or "top" to find out which application is slow (it might be
not Mosaic, but the X server!)

- first build that cpu with profiling and find out what exactly eats up
excessive cpu time.  Its not that hard; the libraries are around in a
profiled version, anyway. It might well be a library function, not the
application itself.

Regards,
        Ignatios