Hi Sebastian, I'm sorry I'm a bit slow in understanding - could you please answer my further questions?
On Tue, 21 Sep 2010 21:18:47 +0200 Sebastian Andrzej Siewior <sebast...@breakpoint.cc> wrote: > * Sergei Poselenov | 2010-09-21 14:09:24 [+0400]: > > >Hello Sebastian, > Hi Sergei, > > >BTW, do you know - why the separate target for e500? Is the > >instruction set for e500 so fundamentally different it needs a > >special configuration for GCC? Why GCC cannot switch codegeneration > >at run-time, conditioning on "-mcpu=e500"? > > Because the ABI is different. All you need to the same output as with > the tripplet you have to specify > -mcpu=mpc8540 -misel -mfloat-gprs=double > So with the tripplet you set all this flags as default (unless I > forgot a switch). -mfloat-gprs changes the ABI from hardfloat to Probably also -mabi=spe? > softfloat. That means you can't mix the binaries, they are not longer > compatible. > I hope I understand now. You mean I can't build an application in the following way: powerpc-linux-gcc -o t.o -c t.c -mcpu=mpc8540 -misel -mfloat-gprs=double -mabi=spe powerpc-linux-gcc -o t t.o In the first step, I built an object with ABI=spe, on the second - I'm linking the object with libc.so, which is built with the "default" powerpc ABI. I can't do this, the objects (.o and libc.so and startup modules (crt..)) are incompatible, right? > >Having the separate target looks inconvenient for me - you have to > >"push" the target to all package, so they wouldn't fail on "configure > >--target=powerpc-linux-gnuspe". > > No, you don't have. The dpkg-architecure command on powerpcspe port > returns: > > |# dpkg-architecture |grep TYPE > |DEB_BUILD_GNU_TYPE=powerpc-linux-gnuspe > |DEB_HOST_GNU_TYPE=powerpc-linux-gnuspe > > That means all packages that pass --target usually go for > DEB_HOST_GNU_TYPE. If you don't specify anything i.e. a simply > ./configure then it is also correct since it goes for gcc which has > allready the correct default. > Not sure I understood. I mean the bug list for the powerpcspe http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=powerpcspe;users=debian-powerpc...@breakpoint.cc port is full of patches which essentially add the new powerpcspe configuration target to a lot of packages. I mean - if you use the traditional "powerpc-linux-gnu" target for you port with the e500v2 GCC options enabled by one or other way - you don't need to bother with the new "gnuspe" target support in a lot of packages. Why the decision to use the gnuspe target? > >> Yes I can reproduce it on 4.3. > >> > > > >This is bad. Does this mean the modern GCC cannot be used for e500 > >currently? > > Some testcases pass, some don't. So yes you may get invalid code. To > workaround you can disable scheduling in gcc as pointed out in the PR. > You can probably also avoid the bug if you use -mfloat-gprs=single. > Yes, we are considering to use the -mfloat-gprs=single as a workaround for our port. Thanks. > >Mmm, do you mean that you are running the Debian rebuilt with gnuspe > >GCC and [0] binutils fix? > Yes that is the case. > > >Have you considered to fix the "lwsync" problem in kernel? I mean > >to catch the Illegal Instruction exception and switch the faulted > >lwsync to sync? > I've been thinking about it but didn't go for it. The problem with > that solution is that you are required to emulate the floating point > code in kernel leaving the "floating unit" untouched. I posted some > numbers here [0] and there [1] and it didn't look good. So the result > is not worth it. > > [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520877#48 > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575158#57 > Understood. Definitely, FP emulation is worse than natural computing. Thanks a lot for your replies! Regards, Sergei > > > >Regards, > >Sergei > > Sebastian -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100922154939.43af6...@emcraft.com
