Subject: Re: I want to rid ugly float load/stores used only for data movement
To: None <,>
From: M L Riechers Mlr <>
List: port-powerpc
Date: 02/23/2003 00:15:32
On Sun, 23 Feb 2003 13:19:06 +1100 Simon Burge
<> asked:

> [ Dropping port-macppc for this reply ]
> On Sat, Feb 22, 2003 at 05:16:25PM -0500, M L Riechers wrote:
> > Until the "soft-float" options work altogether properly for powerpc,
> > which, it looks like at the very least waiting for gcc-3.3, I've
> > adapted the floating point kernel emulation routines from Walnut.  It
> > more or less works (shot 1 bug, diddled another, and at least 1 more
> > identified but not located), but it's molasses slow. Ok, I understand
> > that trips to the kernel are expensive.
> I'm curious about this bit more than the generic gcc+FP issues.  I'm
> using a "MKSOFTFLOAT=yes" built world on my walnut and haven't noticed
> anything wrong in day-to-day usage.  Could you please give some details
> on what bugs you've seen (and the fixes you have!), and also describe
> ``Until the "soft-float" options work altogether properly for powerpc''?

Yes, certainly, and thank you for your interest.

I used the term "work altogether properly for powerpc" with a bit of
trepidition.  Actually, it works well, almost all of the time.
However, there are some key failure points, at least with the 1.5v
version I started with.

I built the first mpc860 from the Tsubai Masanari/David
Querbach/Arne( development line in August 2001,
and changed and added to it.  (I have a Netbsd macppc 7500 that I use
for development, and for this early work I gave the mpc860 its own
disc network mounted from the 7500.  To compile I chroot the 7500 to
the mpc860 disc and compile away.) The build was NetBSD current 1.5v,
and used soft_float universally, and for the most part worked.
However, when run from the mpc860 ld would core-dump, although gcc
seemed to run ok, rwhod would core-dump by (probably recursively)
overflowing the stack, and awk failed unless statically linked.  There
were other failures that I didn't track.  At the time I chalked it all
up to some failure passing float values in GP regs.  But I no longer
think that it was that simple.

Also, Perl would not compile, because of other failures.

Progressing on, in June-July-August I attempted to upgrade to NetBSD
release 1.6 -- both the 7500 and the mbx together.  The Mac went fine,
but the mbx (attempting to build the world with SOFT_FLOAT) did not.
The 1.6 build system forced a situation that both gcc and the float
libraries attempted to provide, for example, the "__divsf3" support
routine, and I couldn't figure out how to make the one or the other
win.  If you're interested, check my post to tech-toolchain 08/10/2002
02:47:54 "using _SOFT_FLOAT and MKSOFTFLOAT=yes with".  It
gives a bit more history and background.

Getting no response to my post, I decided to leave the perplexities of
soft-float for the time being, and import the Walnut emulator.  After
that, everything seemed to work fine, only much more slowly.

Except, there were, bugs:

1.  There was a mistake in the 1.6 libc bzero.S routine using the
    cache for 128-bit cache line machines.  There is also at least one
    other error in bzero that I've yet to identify.  I simply
    commented out all of the cache stuff.

2.  There is a grizzly error in the powerpc mmmmap in mem.c: should be
    returning "atop(off)" instead of "off" (right? or is this just a
    side effect of mine? Need time to analize.)

3.  The dbtst (don't kick me if that instruction isn't right -- I'm
    seat-of-pants here) in caused a bizarre dsi exception.

4.  The float emulator didn't handle single precision float loads

5.  The float emulator corrupted the CR register because of a (int)
    type that should be (u_int) (negative bit propagation problem).

There are some other bugs I half-remember I found.  There is another
bug in the FP emulation I haven't found.  I promise, as soon as
someone doesn't have a gun to my head to finish this project, I'll
hunt down and file PR's with fixes on all of these bugs.  But I gotta
get my customers off my back.

Now from here, I added PCI support, Keyboard, mouse, IDE support, a
crt driver, X windows using a Chips (Asiliant) 69000, support for the
4 scc ports, and whipped the pmap into reasonable shape.  The kernel
uses Instruction Caching, and limited Data Caching, but userland is
still uncached. Touchscreen is next.

It's the X windows server and clients that seem to tip the bugs.

It takes 3 or 4 minutes (instead of 3 or 4 seconds) to load the X
server.  The majority of that time seems to be the float load/store
thing, although X tends to use floating point a good deal more than
your average program.

> >From a toolchain POV, the biggest problem is no way of identifying
> soft-float objects from hard-float objects.  This pretty much
> means that I've had to be careful with package builds, but keeping
> "MKSOFTFLOAT=yes" in /etc/mk.conf helps....

Yes.  That's why, up to this point, I've resisted mixing systems,
sticking entirely to all soft-float or emulation.  But selectively
I've compiled programs -static under 1.6v soft-float environment and
installed them in the 1.6 emulation world.  I did this to top.  It
runs fine, uses only 2% of available resources (vs the top with
emuated FP instructions), but, of course, doesn't have the new top's
info concerning 1.6.  Interestingly, I have a dynamic bash shell left
over from 1.5v, soft-float, and it too runs well.  It links with older
libraries which are compatible.  A left-over emacs, however, didn't
work worth a hoot.  That sort of things' a crap-shoot.

I believe that the mpc823/mpc860 and probably the ibm 405 _world_
ought to be built SOFT-FLOAT, but I lack the confidence to bet the
farm on it at the crunch.  I would love to build the X server, and
some clients, SOFT-FLOAT, (-static would be ok), but, short of a total
system build, I don't know how.  I'm gun-shy at the moment, preferring
the devil I know to the one I don't.  I think there might be compiler
problems with 2.92 (NetBSD 1.5v), and 2.95, and possibly some work
with the soft-float libraries; however, Jason says that gcc 3.2
doesn't work for powerpc, but 3.3 should.  That's March 1, if all goes
well, and I'm running out of time.

But having said that, I would gratefully appreciate any tips you could
pass on for me to successfully build SOFT-FLOAT programs outside of
the way I'm doing it now.  Please understand I'm a relative newbe at
that sort of thing.

> ...This is something I keep
> meaning to look at one day, but still haven't gotten around to.
> The fact that there appears to be no powerpc elf supplement owner
> didn't help :-(
> Simon.
> --
> Simon Burge                                   <>
> NetBSD Development, Support and Service:

Puzzlement here.  I'm aware of the powerpc elf EABI, but I don't know
what a powerpc elf supplement owner is.

Anyway, I hope this rambling discourse has answered some of your
questions.  Please feel free to inquire further if you feel so moved.