GLIBC wont compile for MPC860

GLIBC wont compile for MPC860

[Brendan Simon]

I am using egcs-1.1.2 powerpc-linux cross-compiler to compile
glibc-2.1.1.  The whole thing compiles fine (gee, doesn't it take a
while).

I tried compiling for the MPC860 with the following command "make
CFLAGS=-mcpu=860".  It got a little way but then died.  I think it is
trying to do something with floating point.

Is glibc known to compile for this processor ?
I'm pretty sure I need the -mcpu=860 option so that only mpc860 valid
instructions are generated.  Is this correct ?

I don't have the error message at hand but will post it if it will help.

What can I do to compile glibc for the MPC860 processor.

Thanks,
Brendan Simon.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: GLIBC wont compile for MPC860

[Scott Wood]

Brendan Simon wrote:
> 
> I am using egcs-1.1.2 powerpc-linux cross-compiler to compile
> glibc-2.1.1.  The whole thing compiles fine (gee, doesn't it take a
> while).

> 
> I tried compiling for the MPC860 with the following command "make
> CFLAGS=-mcpu=860".  It got a little way but then died.  I think it is
> trying to do something with floating point.
> 

The MPC8xx have no floating point, so it should be compiled with -msoft-float,
(I think)...  ./configure --without-fp  will do it.

> Is glibc known to compile for this processor ?
> I'm pretty sure I need the -mcpu=860 option so that only mpc860 valid
> instructions are generated.  Is this correct ?
> 

I have tried this both with the egcs cross-compiler and with egcs on an
MPC750 and I have recieved 'internal compiler error' both times, but I'm trying
again.

> I don't have the error message at hand but will post it if it will help.
> 
> What can I do to compile glibc for the MPC860 processor.
> 

I would also like to know how to sucessfully build glibc for the MPC850.

-- 
+---------------------+----------------------+
|     Scott Wood      |   Systems  Engineer  |
|=====================+======================|
|           BroadLink Communications         |
+--------------------------------------------+

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: GLIBC wont compile for MPC860

[Graham Stoney]

Scott Wood writes:
> The MPC8xx have no floating point, so it should be compiled with -msoft-float,
> (I think)...  ./configure --without-fp  will do it.

Is this implied when gcc has been configured --with-cpu=860?

Thanks,
Graham

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: GLIBC wont compile for MPC860

[Scott Wood]

Graham Stoney wrote:
> 
> Scott Wood writes:
> > The MPC8xx have no floating point, so it should be compiled with -msoft-float,
> > (I think)...  ./configure --without-fp  will do it.
> 
> Is this implied when gcc has been configured --with-cpu=860?

I don't think so...  I put -msoft-float into the sysdeps/powerpc/Makefile and I see
it twice below, so I would imagine that if you use both flags then -msoft-float
will be used.

I am using YellowDog Linux now and instead of an 'internal compiler error',
I get:

make[1]: Entering directory `/usr/src/redhat/SOURCES/glibc-2.1.1/math'
gcc ../sysdeps/powerpc/s_isnan.c -c -Wall -Winline -Wstrict-prototypes -Wwrite-strings -mcpu=860 -msoft-float   -fpic
-msoft-float   -Wno-uninitialized -Wno-write-strings  -I../include -I.  -I.. -I../libio  -I../sysdeps/powerpc/elf
-I../sysdeps/unix/sysv/linux/powerpc -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/powerpc -I../sysdeps/wordsize-32
-I../sysdeps/ieee754 -I../sysdeps/libm-ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic    -include
../include/libc-symbols.h  -DPIC   -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -DNO_LONG_DOUBLE -D_Mlong_double_=double -o
s_isnan.os
../sysdeps/powerpc/s_isnan.c: In function `__isnan':
../sysdeps/powerpc/s_isnan.c:32: fixed or forbidden register 32 (0) was spilled for class FLOAT_REGS.
This may be due to a compiler bug or to impossible asm
statements or clauses.
make[1]: *** [s_isnan.os] Error 1

I haven't even got a PowerPC 750 native build to work yet (even
though I ran configure with the --disable-time and --disable-db2 options).  Any
idea how I can exclude db2 (and other unnecessary things like locale and nis) 
support so I can get a (c)lean build?  

I have been able to run many static binaries compiled for the 750 with
--msoft-float on the MPC850 just fine, although snmpd and dhcpd segfault.  The
glibc should work as well if it doesn't do hardware floating point, but it doesn't
seem to compile without it.

-Scott

> 
> Thanks,
> Graham

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: GLIBC wont compile for MPC860

[David Edelsohn]

>>>>> Scott Wood writes:

Scott> Graham Stoney wrote:
>> 
>> Scott Wood writes:
>> > The MPC8xx have no floating point, so it should be compiled with -msoft-float,
>> > (I think)...  ./configure --without-fp  will do it.
>> 
>> Is this implied when gcc has been configured --with-cpu=860?

Scott> I don't think so...  I put -msoft-float into the sysdeps/powerpc/Makefile and I see
Scott> it twice below, so I would imagine that if you use both flags then -msoft-float
Scott> will be used.

	Unfortunately, the people who wrote PowerPC support for glibc did
not create a sysdeps/powerpc/fpu directory containing FP-specific code.
There currently is no way to disable FP code in glibc-2.1, but I believe
that the maintainers were suppose to fix this for glibc-2.2; I do not know
about the status.  People who have been working on Linux for embedded
processors have been building glibc somehow, but I do not know the details.

David
===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 914 945 4364 (TL 862)                            Yorktown Heights, NY 10598

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: GLIBC wont compile for MPC860

[Marcus Sundberg]

[-- Attachment #1: Type: text/plain, Size: 5255 bytes --]

Hi,

first note the "Reply To" - we have a new list, so why not use it.

Scott Wood wrote:
> 
> Graham Stoney wrote:
> >
> > Scott Wood writes:
> > > The MPC8xx have no floating point, so it should be compiled with -msoft-float,
> > > (I think)...  ./configure --without-fp  will do it.
> >
> > Is this implied when gcc has been configured --with-cpu=860?

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}

Likewise, passing -mcpu=860 to gcc will imply -msoft-float, but
not -D_SOFT_FLOAT. So either fix your specs file or always
explicitly pass -msoft-float to gcc.

> I don't think so...  I put -msoft-float into the sysdeps/powerpc/Makefile and I see
> it twice below, so I would imagine that if you use both flags then -msoft-float
> will be used.
> 
> I am using YellowDog Linux now and instead of an 'internal compiler error',
> I get:
> 
> make[1]: Entering directory `/usr/src/redhat/SOURCES/glibc-2.1.1/math'
> gcc ../sysdeps/powerpc/s_isnan.c -c -Wall -Winline -Wstrict-prototypes -Wwrite-strings -mcpu=860 -msoft-float   -fpic
> -msoft-float   -Wno-uninitialized -Wno-write-strings  -I../include -I.  -I.. -I../libio  -I../sysdeps/powerpc/elf
> -I../sysdeps/unix/sysv/linux/powerpc -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman
> -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/powerpc -I../sysdeps/wordsize-32
> -I../sysdeps/ieee754 -I../sysdeps/libm-ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic    -include
> ../include/libc-symbols.h  -DPIC   -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -DNO_LONG_DOUBLE -D_Mlong_double_=double -o
> s_isnan.os
> ../sysdeps/powerpc/s_isnan.c: In function `__isnan':
> ../sysdeps/powerpc/s_isnan.c:32: fixed or forbidden register 32 (0) was spilled for class FLOAT_REGS.
> This may be due to a compiler bug or to impossible asm
> statements or clauses.
> make[1]: *** [s_isnan.os] Error 1

Ok, here's how to build glibc for embedded PPC:

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:

diff -ur orig/glibc-2.1.1/sysdeps/powerpc/dl-machine.c glibc-2.1.1/sysdeps/powerpc/dl-machine.c
--- orig/glibc-2.1.1/sysdeps/powerpc/dl-machine.c       Fri Mar  5 23:41:23 1999
+++ glibc-2.1.1/sysdeps/powerpc/dl-machine.c    Mon May 17 20:59:06 1999
@@ -250,7 +250,11 @@
         PowerPC processors have line sizes of exactly 32 bytes.  */
 
       size_modified = lazy ? rel_offset_words : PLT_INITIAL_ENTRY_WORDS;
+#ifdef PPC_CACHELINESIZE_32
       for (i = 0; i < size_modified; i+= 8)
+#else
+      for (i = 0; i < size_modified; i+= 4)
+#endif
        PPC_DCBST (plt + i);
       PPC_DCBST (plt + size_modified - 1);
       PPC_SYNC;

(The ifdef is bogus - PPC_CACHELINESIZE_32 is actually never defined,
and this should really be handled runtime anyway. The problem is that
reading the PVR is a supervisor level operation for some stupid reason,
and afaik there is no other way to find out what the line size is.
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.)

Secondly you will want to remove the floating point assembler.
This is done by piping the following diff into the attached script
(with sysdeps/powerpc as your cwd):

diff -ur orig/glibc-2.1.1/sysdeps/powerpc/Dist glibc-2.1.1/sysdeps/powerpc/Dist
--- orig/glibc-2.1.1/sysdeps/powerpc/Dist       Tue Sep 15 00:57:08 1998
+++ glibc-2.1.1/sysdeps/powerpc/Dist    Tue May  4 17:00:33 1999
@@ -1,7 +1,3 @@
 dl-machine.c
 dl-start.S
-fenv_const.c
-fenv_libc.h
 ppc-mcount.S
-fe_nomask.c
-t_sqrt.c
diff -ur orig/glibc-2.1.1/sysdeps/powerpc/Makefile glibc-2.1.1/sysdeps/powerpc/Makefile
--- orig/glibc-2.1.1/sysdeps/powerpc/Makefile   Wed Nov 18 00:48:00 1998
+++ glibc-2.1.1/sysdeps/powerpc/Makefile        Tue May  4 17:01:07 1999
@@ -1,7 +1,3 @@
-ifeq ($(subdir),math)
-libm-support += fenv_const fe_nomask t_sqrt
-endif
-
 ifeq ($(subdir),gmon)
 sysdep_routines += ppc-mcount
 endif

Now you can simply configure glibc with --without-fp and build it.
It is possible that some of the more advanced stuff in the math
library will not work - I get warnings about fe_* functions being
stubs, but as I have no idea of what a "floating point environment"
is or how to implement it when using soft floats it's nothing I can
do about it. Most programs work fine here.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se

[-- Attachment #2: glibcpatch --]
[-- Type: text/plain, Size: 940 bytes --]

#!/bin/sh

FPUFILES="
Versions
bits/fenv.h
bits/mathdef.h
bits/mathinline.h
e_sqrt.c
e_sqrtf.c
fclrexcpt.c
fe_nomask.c
fegetenv.c
fegetround.c
feholdexcpt.c
fenv_const.c
fenv_libc.h
fesetenv.c
fesetround.c
feupdateenv.c
fgetexcptflg.c
fpu_control.h
fraiseexcpt.c
fsetexcptflg.c
ftestexcept.c
s_copysign.S
s_copysignf.S
s_fabs.S
s_fabsf.S
s_fmax.S
s_fmaxf.S
s_fmin.S
s_fminf.S
s_isnan.c
s_isnanf.S
s_lrint.c
s_lrintf.S
s_rint.c
s_rintf.c
t_sqrt.c
w_sqrt.c
w_sqrtf.c
"

FPUDISTFILES="fenv_const.c
fenv_libc.h
fe_nomask.c
t_sqrt.c
"

MAKEFILE='-ifeq ($(subdir),math)
-libm-support += fenv_const fe_nomask t_sqrt
-endif'

patch -p1

cd sysdeps/powerpc #|| exit 1
mkdir -p fpu/bits || exit 2

for a in $FPUFILES; do
  mv "$a" "fpu/$a" && echo "Moved $a -> fpu/$a"
done

fail=
for a in $FPUDISTFILES; do
  echo "$a" >> fpu/Dist || fail=1
done
test "$fail" || echo "Created fpu/Dist"

echo "$MAKEFILE" >fpu/Makefile && echo "Created fpu/Makefile"

Re: GLIBC wont compile for MPC860

[Graham Stoney]

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

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

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

> 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

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: GLIBC wont compile for MPC860

[Michael Meissner]

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

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

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

Re: GLIBC wont compile for MPC860

[Marcus Sundberg]

Graham Stoney wrote:
> 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...

Yes definitely. I intend to submit some patches as soon as I've had
time to try out glibc 2.1.2pre3 and verified that there are no
problems with that. Don't know if I will have time before they
release the final 2.1.2 though. :(

> Marcus Sundberg writes:
> > 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?

Yes, it will cause _SOFT_FLOAT to be defined unless you pass
-mhard-float to gcc, but see below.

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

I'm not really sure what goes on in gcc. I configured my gcc with
--with-cpu=860 and --nfp, and even if I pass -mcpu=750 -mhard-float
it doesn't generate floating point instructions... This is not a problem
for me as I don't have any non-860 CPU's to compile code for, but this
also means that I don't know what you should do to build a compiler that
generates 860 code by default and also is capable of generate code for
other CPUs.

> > 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 like the former solution. Having the compiler keep track of what
line sizes different CPUs have is good, but forcing other user-land
code to know this isn't nice IMHO.

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

Yep, I have no problem with having it a compile-time option either,
but some people want to run standard LinuxPPC libraries and binaries
on 8xx, so then a run-time check is needed as well.

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

Speaking of FPU code, I just noticed that there is an FPU emulator
for PPC included in Linux version 2.3.16. We really don't need that 
here, but others might find that very interresting...

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: GLIBC wont compile for MPC860

[Dan Malek]

Marcus Sundberg wrote:

> Yes definitely. I intend to submit some patches as soon.....

Thank you.  This was discussed years ago when we first started
the 8xx port, but nothing was ever done in the old libraries.
I just used to make the couple of changes in the code and compile
with the -mcpu=860 flag and post the binaries on the server.

I don't mind doing that again.  If you don't get the patches
into the general release, just put them somwhere the rest of
us can find them.

Some of us actually creating embedded applications in this space
are a little concerned with the size of glibc2, and I suspect
we will be doing some major hacking to fit some of the smaller
environments.

> ..... but this
> also means that I don't know what you should do to build a compiler that
> generates 860 code by default and also is capable of generate code for
> other CPUs.

I don't know if this is important.  Most of us are used to using the
proper flags, want to use the same compiler on our Linux/PPC Macs
as is used for the other processors.  With the new 82xx stuff
coming up now, a different set of flags are necessary, and the
compiler supports it just fine.


 
> I like the former solution. Having the compiler keep track of what
> line sizes different CPUs have is good, but forcing other user-land
> code to know this isn't nice IMHO.

Well, see the comment below.  There is some merit to using a
standard binary distribution on all processors.  I have even
attempted to pass this information from the kernel through the
run-time startup as a variable, as most people don't want the
overhead of system calls to determine this.


> Yep, I have no problem with having it a compile-time option either,
> but some people want to run standard LinuxPPC libraries and binaries
> on 8xx, so then a run-time check is needed as well.

I get lots of requests for the standard distribution libraries
to run.  I put the couple of floating point hacks in the original
port just to get past the set/long jump FP load/stores.  Some
programs will run (like the shell) but not much else.

Keep in mind that just having the library isn't enough, you have
to compile all of the programs you want to use as well.


> Speaking of FPU code, I just noticed that there is an FPU emulator
> for PPC included in Linux version 2.3.16. We really don't need that
> here, but others might find that very interresting...


That has been on and off for a long time as well.  It is there
to specifically support the 8xx (and now 8260) using standard
distribution libraries.  I am just now porting that kernel version
to the 8xx, so we'll see how it works....

Don't get any ideas about using it for much, the performance of
floating point emulation on the 8xx is pathetic, trapping into
the kernel makes it pretty useless except for supporting the
generic PPC binary distribution.  For real product applications,
I first try to avoid any floating point, and then convert anything
else to fixed point.

In general, for all of the real world products I have done
using Linux/PPC and 8xx, I use the old libc-1.99 and static
linking.  Don't forget about trying that, as it could result
in the smallest (and fastest) executables.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: GLIBC wont compile for MPC860

[Grant Erickson]

On Fri, 3 Sep 1999, Dan Malek wrote:
> Marcus Sundberg wrote:
> > Yes definitely. I intend to submit some patches as soon.....
> 
> Thank you.  This was discussed years ago when we first started
> the 8xx port, but nothing was ever done in the old libraries.
> I just used to make the couple of changes in the code and compile
> with the -mcpu=860 flag and post the binaries on the server.

I'd rather see the patches in sooner than later. At present, I'm playing
around with the IBM 403GCX and there seem to be a large number of
similarities between the issues faced by the 8XX community and those faced
by the 40X community.

> That has been on and off for a long time as well.  It is there
> to specifically support the 8xx (and now 8260) using standard
> distribution libraries.  I am just now porting that kernel version
> to the 8xx, so we'll see how it works....

Hopefully, I'll get a chance to run it against the 403 as well when I get
to that point.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: GLIBC wont compile for MPC860

[Graham Stoney]

Dan Malek writes:
> Some of us actually creating embedded applications in this space
> are a little concerned with the size of glibc2, and I suspect
> we will be doing some major hacking to fit some of the smaller
> environments.

I think newlib would be a promising candidate given its emphasis on small size,
although the current version needs some porting work to run under Linux/PPC.
My application also needs threads, but I'm hoping I might be able to drop
LinuxThreads from glibc into newlib without too much bloat. For a first cut
though, I'll just drop lots of RAM in and link statically against glibc-2.1.2.

> > ..... but this
> > also means that I don't know what you should do to build a compiler that
> > generates 860 code by default and also is capable of generate code for
> > other CPUs.
> 
> I don't know if this is important.  Most of us are used to using the
> proper flags, want to use the same compiler on our Linux/PPC Macs
> as is used for the other processors.  With the new 82xx stuff
> coming up now, a different set of flags are necessary, and the
> compiler supports it just fine.

Sure, but I'm cross compiling from an Intel box and it would be nice to be able
to configure a gcc --with-cpu=860 and have it imply -msoft-float, -D_SOFT_FLOAT
and whatever else is needed when building glibc/newlib etc.

> > I like the former solution. Having the compiler keep track of what
> > line sizes different CPUs have is good, but forcing other user-land
> > code to know this isn't nice IMHO.
> 
> Well, see the comment below.  There is some merit to using a
> standard binary distribution on all processors.

Sure; I agree 100%. The tiny extra bloat involved to retain binary
compatibility seems worth it even for an embedded app.

> In general, for all of the real world products I have done
> using Linux/PPC and 8xx, I use the old libc-1.99 and static
> linking.  Don't forget about trying that, as it could result
> in the smallest (and fastest) executables.

Any chance you could put your libc-1.99 (or a pointer to it) up at
ftp://linuxppc.cs.nmt.edu/pub/linuxppc/embedded/ ?

Thanks,
Graham

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: GLIBC wont compile for MPC860

[Dan Malek]

Graham Stoney wrote:


> I think newlib would be a promising candidate given its emphasis on small size,

Yeah, I suppose we should look at it.  It is nice to use something
already ported and compiled for the PPC, though.  Keeping it all
in the family makes it much easier as lots of other people are
using it.


> My application also needs threads, but I'm hoping I might be able to drop

I just use clone() straight away and I like the implementation
of Linux threads.


> ...I'll just drop lots of RAM in and link statically against glibc-2.1.2.

You may not need lots of RAM for a static linked application.  The
linker only pulls what it needs form the library.  I have done
several applications where static linking required both less
file system storage and real memory space.


> Sure, but I'm cross compiling from an Intel box and it would be nice to be able


If you ever used a Linux/PPC development host (IBM, Motorola, Apple)
you would never use an Intel box for this stuff.  It is so much
faster and easier with a PPC host.


> Any chance you could put your libc-1.99 (or a pointer to it) up at
> ftp://linuxppc.cs.nmt.edu/pub/linuxppc/embedded/ ?

It's been there a long time....libc-1.99-8xx.somthing_or_other.
It's compiled with the -mcpu=860 flag, has the cache line stuff
patched (so you can run copyback on the 8xx), and has the floating
point assembler instructions removed.  It was built from
glibc-0.961212-1o, and is a tar image.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/