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
name.
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
port
* 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
vfpv3-d16)
* 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.
Cheers,
--
Loïc Minier