Thread (1 message) 1 message, 1 author, 1999-09-03

Re: GLIBC wont compile for MPC860

From: Michael Meissner <hidden>
Date: 1999-09-03 02:40:03

On Fri, Sep 03, 1999 at 12:15:34PM +1000, Graham Stoney wrote:
Hi Marcus,

Thanks for your great tips on building glibc for the '860. It would be great if
we could get some mods into the next glibc release so that it would configure
out-of-the-box without patching...

Marcus Sundberg writes:
quoted
Configuring gcc with --with-cpu=860 and --nfp will make the
_compiler_ default to -msoft-float. It will however _not_ make the 
pre-processor define -D_SOFT_FLOAT by default, which will cause
all variable arguments functions taking floating point arguments
(like the *print[fs] family) to be mis-compiled.

The fix is to add this code to your gcc's 'specs' file under the
section '*cpp_sysv':
%{!mhard-float: -D_SOFT_FLOAT}
Is this a general fix though; won't it cause _SOFT_FLOAT to be defined by
default for all other cpu types as well?

The specs file from gcc 2.95.1 includes '%{mcpu=403: -D_SOFT_FLOAT}' in the
cpp_sysv rule, and adding '%{mcpu=860: -D_SOFT_FLOAT}' has the advantage of not
affecting other cpu types. Problem is, it only kicks in when I pass -mcpu=860
explicitly, even though I configured gcc --with-cpu=860. I'm confused...
Because I forgot about --with-cpu=xxx.  Sigh.  I'll try to get to it tomorrorow
in the egcs tree.
quoted
First you must remove the assumption that cachelines are 32 bytes:
Apply this diff, and simply move sysdeps/powerpc/memset.S out of the
way for now:
Perhaps the gcc specs file could have a #define for the cache line size, so
this is also automatically set via the -mcpu option. Alternatively, a #define
giving the -mcpu= value would allow the code to work this out, kind of like the
__i386, __i486, __i586 family for x86 architectures. There doesn't seem to be
an equivalent for PowerPC's at present.
I would prefer not to define the cache size.
quoted
My vote is to have a special sysctl entry for the cacheline size,
for fast and easy access (one syscall compared to the open()/read()/close()
triplet for normal /proc entries, and you also don't have to have the
/proc fs mounted), and then cache the result in a static variable.)
I'd be happy with a compile-time option, but I don't mind either way.
quoted
Secondly you will want to remove the floating point assembler.
Cool! It would be nice to get the fpu code re-arranged in the official glibc
too...

Thanks!
Graham
-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help