[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: m68k softfloat builds
On Wed, May 28, 2008 at 17:54:36 +0000, Christos Zoulas wrote:
> In article <20080528020833.GA25377%pix.net@localhost>, Kurt J. Lidl
> <lidl%pix.net@localhost> wrote:
> >A while ago, I ran into a problem trying to build a m68k system
> >with -msoft-float. A reply about the failure is here:
> >Any thoughts about whether or not this is the best way to procede?
> The patch referenced there should be applied regardless if we don't have it
> >I suppose that turning on something like the multilib support in gcc
> >is another way of doing this -- at least that is my understanding
> >of it.
> >I think this is a larger relevance than just the existing m68k ports
> >too. The Freescale Coldfire chips (the 54xx and 54xxx) have an
> >MMU but none have a floating point unit. The gcc 4.3 compiler
> >has support for the coldfire instruction sets (there are slight
> >differences between them all). I've fooled around a bit with
> >trying to get gcc 4.3 to build as a cross compiler for netbsd-current,
> >but haven't had any success yet.
> >If anybody wants to get netbsd running on the coldfire (I certainly
> >do), I think that this whole issue of no-fpu 68k-ish systems will
> >need to be addressed.
> We have many choices:
> 1. always put the softfloat glue in libgcc; pros: no magic library selection,
> easier build process. cons: some size overhead in libgcc [I don't think it
> is much].
> 2. build the softfloat glue only on machines that need it; pros: efficient.
> cons: complex build process, need to figure out crosscompiling, different
> userland flavors for the same platform.
> 3. build the softfloat glue in a separate library, and auto-load it using
> ld.so magic. pros: efficient. cons: more complicated than building a
> single library, relies on ld.so magic.
> My order of preference is best to worst 1, 3, 2. Others? Other ideas?
IIRC, m68k passes all arguments via stack (including fp), so #1 and #3
above should work just fine there.
OTOH, SuperH softfloat vs. hw float makes ABI difference (fp args
passed in general purpose registers vs. fp registers), so you cannot
get away with just supplying the softfloat glue and keep both sw/hw fp
happy at the same time - you need two different userlands. Something
we need to solve too (unfortunately I didn't have time to do
kernel-side FPU support for sh4 in time for NetBSD 5.0).
Since there are platforms (at least sh3) where softfloat changes ABI,
we need to solve this problem for generic case anyway.
uwe%stderr.spb.ru@localhost | Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
Main Index |
Thread Index |