I have a lot of kirkwood, a pi, no armv7, and no $$ atm so Im not anxious to have support dropped. :) I do understand the dilemma..:) I think kirkwood is about the only popular armv5tel but there are other 926 chips running around, and the Cortex A5 only has an optional FPU. The part of the atomics issues are solved with libatomic which is part of the gcc 4.8, and there is something available to 4.7 as well but it isn't built in, you have to link it in. It is essentially a generic atomic functions, for cases where real atomics aren't available or fully supported and an attempt at helping make them more generically supported. I was unable to rebuild gcc from the srpm which stimied a few relevent tests. I was actually wondering if multi-lib support between the armv5tej and the armv6 might be possible?? Then you have a hard/soft float distribution for thumb1 and still can do tricks with jazelle. Then roll with armv7/armv8 as a multilib 64/32. For me, the kirkwood is faster for dev then the raspi is, and the problem with the raspi speed isn't all a Hard float issue. One thing that might be easier that would speed up the builders a bit might be to start precompiling the headers. The other would be to see if thumb1 is actually decently supported. I think you will see a bigger boost with thumb instructions then you will with hardfloat especially given the io constraints on the raspi. thumb2 is actually much better supported and it actually makes more sense to test thumb2 on armv7l+. Does anyone know when the arch started supporting multiple thumb executions per clock? I =would= like to see a full set of packages compiled on all the supported platforms asap. Getting the kinks worked out is just going to help the whole process moving forward for everyone. ----- Original Message ----- > From: Josh Boyer <jwboyer@xxxxxxxxx> > To: Dennis Gilmore <dennis@xxxxxxxx> > Cc: arm@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Friday, January 25, 2013 12:18 PM > Subject: Re: arm software floating point support going forward > > On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore <dennis@xxxxxxxx> wrote: >> Hi all, >> >> I wanted to kick off a discussion, I think that with the work that >> Seneca is doing for armv6hl to support the Raspberry Pi most of the >> need for building sfp has gone away. I would like us to drop support >> for sfp in F19 that means that anyone running a kirkwood based system >> would get supported software updates for approximately 13 months from >> now. with cubie boards and other devices coming around that are cheap >> and more powerful and similar options I think there is little benefit >> to continuing to support sfp. > > I'm not overly familiar with arm, but from a kernel standpoint you might > be able to enable floating point emulation. That would let you run the > hardfp binaries on the boards without an FPU. It would be a performance > hit for things doing FP heavy computation, but you could continue > supporting those boards that way. > > josh > _______________________________________________ > arm mailing list > arm@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/arm > _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
