[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: armelfp: new architecture name for an armel variant

On Tue, Jul 06, 2010, Hector Oron wrote:
> On the other hand, one can imagine providing only a set of optimized
> softfp libraries in addition to the default soft one, that are selected
> at runtime. "
>   -- Aurelien

 So we tried this in Ubuntu, and it doesn't yield much; we had a vfp
 libc6, gtk+2.0, pango1.0, ffmpeg etc.  libc6 (including libm) was
 useful, but the rest was not very impressive, and it is very painful in
 terms of maintenance/development, doesn't scale well.

 hardfp gains much more than softfp because you save the time to
 load/store the FPU registers to the stack, which can be up to 20 cycles
 on Cortex A8.

> " This really has to be decided and agreed *before* we create an archive
> on debian-ports.org and you start building packages. If that changes, we
> have to create a new archive, and everything has to be rebuilt from
> scratch. "

 Full ack

 In fact, I chatted with a couple of people about this port, with the
 proposal that we should have an ad hoc BoF at Debconf to chose a good

 During these chats, I heard other suggestions around a new port
 notably, optimizing for much more recent CPUs such as armv7+.  Ubuntu
 did see quite a difference by moving all the way up to armv7 + thumb-2.

 Some technical issues to be aware of:
 * hard float needs gcc 4.5 or a bunch of patches from 4.4; CodeSourcery
   GCC 4.4 (and hopefully soon Linaro GCC 4.4) has these
 * hard float is quite a win on Cortex A8, but might be much less so
   on A9 -- I think on the long term we want hard float support in a
 * there's the question of which vfp version we turn on, vfpv3 is not
   supported on all armv7 SoCs (e.g. Marvell's Dove only supports
 * some libraries need porting to hard-float, such as libffi and others

> *`armelfp' was suggested*, so what would you think of having such
> architecture name for armel+hardfp port?

 Couple of other proposals: armelhf, or armfp.

> I would also like to comment that genesi-usa has been kind enough to
> provide with hardware (EfikaMX [2]) to some of the leading people on
> Debian projects as Live, Emdebian and Edu. If you want to work on the
> port, there might be a board for you too. Most needed bit to have
> official Debian support for such hardware would be a mainlined kernel,
> which current is built over Pegatron SDK which builds upon Freescale
> SDK. If you are willing to do kernel work for EfikaMX (i.MX515 CPU)
> let us know.

 That's very nice!  In my experience, iMX51 is decently fast and that's
 what we use for Ubuntu buildds, but is not quite fully mainlined, so it
 might be an issue for purists and you might have to stay on slighlty
 older kernels.

 In any case, I very much support the project, thanks for sending this
 out!  I think it's a good topic for Debconf.

Loïc Minier

Reply to: