Dear armel porters,
I am writting this letter to you by out concern of having to pick
up a name for a new armel architecture variant optimized for hard
floating point, instead soft floating point.
Konstantinos (and I shall be also supporting him) is willing to
maintain a new architecture for Debian at least in an unofficial way
at debian-ports.org.
Before this email, we have crossed, also with Aurelien Jarno, some
private emails which I'll be quoting here for better understanding:
> What is this new architecture? Is there a huge difference compared to
> building only a few libraries with hardfp?
Konstantinos has done a proof of concept built for Ubuntu Karmic and
he has got some interesting results [1]
" There are 3 ABIs in armel right now, regarding the use of the fpu: a) soft (no
fpu used, all fpu math is done software only, using libgcc fallback
functions), b) softfp (the fpu is used, but function arguments are passed
through the integer registers and not the fpu hardware registeres, this
results in unnecessary register moves for every function call that uses
floating point argumetns, c) hardfp, argument passing is properly done using
the fpu registers directly. The result is estimated to save 20 CPU cycles per
function call. Not something to ignore esp. given the embedded nature of ARM
where every cycle is important.
These are configured by the gcc flags: -mfloat-abi={soft,softfp,hard}. Softfp
is the default in pretty much every distro out there (incl. Ubuntu, Debian,
etc). Only some OpenEmbedded builds have enabled hardfp, but these are too
specialized.
Don't ask me why this was so, I don't know the historical reasons for having
this behaviour in ARM cpus. While binaries built using (a) will run on each of
the two other ABIs, softfp and hardfp are incompatible with each other -I know
I tried and I had it verified by ARM engineers as well.
So, in order to test hardfp, one has to build a complete base distro. In order
to have a basic karmic image to test and compare on my efikamx, I had to
rebuild ~4k packages from scratch. The result is, not surprisingly, quite
faster than the default Ubuntu karmic installation on the system, some
preliminary results gave me 20-25% speed increase on exactly the same
software/hardware configuration (eg. glxgears on software mesa reports 145 fps
vs 120 fps). The gain is bound to be bigger or smaller depending on the app
and if it does lots of calls of functions with float/double arguments (which
is of course the case with mesa and 3d).
The only drawback was that I had to use the CodeSourcery compiler, which I
built from source and packaged as a replacement gcc package, which I used to
build everything. The reason is that neither the default Ubuntu nor the Debian
gcc compilers support hardfp -yet, at least.
So... here is the story so far. I now have 9 efikamx systems here, waiting to
be used as a buildd cluster, but I have wanna-build which just busts my balls
and just won't install. I asked the Debian buildd guys, and they just
confirmed that there is neither documentation nor enough testing outside the
Debian default buildd systems. I also considered soyuz (the Ubuntu
alternative) but it's still not available as standalone -it needs the complete
Launchpad to work properly, at least now.
So, any ideas, beside building 20k packages by hand? :) "
-- Konstantinos
I think you should be aware Konstantinos is a retired DD and he might
enroll again Debian via NM if posible.
" That would be nice to compare hardfp with softfp, and to do it from the
user experience point of view. Of course it is always possible to find a
software that benefits greatly the change, like glxgears.
hardfp has the main disadvantage that it is not compatible with CPU
without FPU.
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
Aurelien also adds to Konstantinos suggestion:
" > Personally, I think the best choice would be to go for something
like armelfp
> (who knows, armeb might have the same dilemma in the future)."
-- Konstantinos
" 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. "
So, now, it is up to you, dear armel porters if we can have an
official name scheme for such architecture to be added to dpkg
architecture tables.
*`armelfp' was suggested*, so what would you think of having such
architecture name for armel+hardfp port?
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.
Best Regards,
[1] http://www.powerdeveloper.org/forums/viewtopic.php?p=13609
[2] http://www.genesi-usa.com/products/efika
--
Héctor Orón
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktimoasv_lxmtplp3aqv9vdm5gx-31tu7pqni6...@mail.gmail.com
