Hi,
ext Jeremiah Foster wrote:
On Oct 27, 2010, at 07:07, <[email protected]<mailto:[email protected]>>
<[email protected]<mailto:[email protected]>> wrote:
1.1 schedule for hardfp would be *very* challenging since we are still working
in order to get hardfp toolchain working. After that testing (incl. performance
testing) can be start.
What are the issues in getting a working MeeGo hardfp toolchain?
From: Arjan van de Ven [[email protected]]
Sent: Tuesday, October 26, 2010 10:24 PM
On 10/26/2010 12:18 PM, Quim Gil wrote:
On Mon, 2010-10-25 at 23:52 +0200, ext Thiago Macieira wrote:
This is why I was wondering why we're not using hardfp *now* for 1.1.0.
We shouldn't be breaking binary compatibility.
We shouldn't be softp either.
Just reminding the obvious, but as for today there is no major MeeGo
products in the market, no AppUp for MeeGo, no Ovi for MeeGo, no Extras
for MeeGo. Even the MeeGo SDK itself is in its first iterations.
which will change once we release 1.1.
I fully argee with Quim here, we have to act on this now, when the installed
base does not exist.
It does seem an advantage to act now in order to impose the least amount of
disruption possible on the installed user base.
Can we sketch out a roadmap? It seems evident that a MeeGo 1.1 hardfloat is
difficult.
According to this (first Google hit):
http://wiki.meego.com/Release_Engineering/Plans/1.1
1.1 is going to be released now?
How difficult will a 1.2 be? And if the toolchain is prepared for building a
hardfloat 1.2,
then we should build in parallel, as if this was a separate port, correct?
(This is in fact what Debian does, their ARM hardfloat is essentially a
separate port.)
If this path is the appropriate path
I don't see any point in softfp once hardfp is working fine (see below).
then we might need a target end of life of
the softfloat ARM port, how do we identify that?
Needs identifying what are the toolchain issues and what SW will
be impacted[1].
-> 1.1 release notes should at least state that there's a partial
ABI break coming and for 99% of apps re-compile is enough?
[1] Only things generating assembly instructions directly[2] need
changes for hardfp, and only if the generated code is calling
floating point functions directly.
[2] See e.g. Debian's TODO for full list of impacted SW:
http://wiki.debian.org/ArmHardFloatTodo
I see Arjan's point made from an architecture consistency point of view
- but from a marketing point of view 1.2 and following releases will be
a lot more used and scrutinized than 1.1.x releases. If this soft-hard
break is unavoidable then it seems that now it will create a lot less
hassle than in 6 months or later.
based on the discussion here... the technology is at least several
months away.
>
There is work underway already. Already ~80% of the main Debian archive
is being built against the hardfloat port.
https://wiki.linaro.org/Linaro-arm-hardfloat
and breaking compatibility in an upgrade is even worse than breaking it
n a new release...
.... really.
Clearly MeeGo ought to be following your advice. But I think that
you may be persuaded if we take into account;
1. There is a significant set of optimizations in the hardfloat ARM port [0.]
2. ARM softfloat will be less relevant once a hardfloat is present
Not just less relevant, but irrelevant. Softfp already implies
HW having VFP.
Only point of "softfp" is function call ABI compatibility with
non-VFP "soft" (= fp emulation) software, but as "soft" would be
a *huge* performance penalty on VFP capable HW, it think it actually
a good thing that it's not supported... That way nobody does it
accidentally. :-)
3. Much of the ARM Linux community is already moving in this direction
0. http://www.powerdeveloper.org/forums/viewtopic.php?t=1821
We need to address those concerns by talking bout this openly.
According to best experts this will take some time, so unfortunatelly
it seems that we will have 2 ARM architecture builds towards 1.2,
and we can only make final judgement when we know that hardfp
will work as intended.
This seems like a logical path forward. Yes there will be some difficulty,
but this seems the only way to ensure that ARM devices are performant as soon
as possible.
- Eero
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
