Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion
On Oct 27, 2010, at 07:07, jarmo.k...@nokia.com jarmo.k...@nokia.com 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. From: Arjan van de Ven [ar...@linux.intel.com] 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. 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 then we might need a target end of life of the softfloat ARM port, how do we identify that? 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 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. Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)
Hi As I said in earlier thread, this is my fault. I should have undesrtood the signifigance and start that work early enough in MeeGo so we would have had change to get it into 1.1 already. My only defence is that this is pretty new stuff, and for the record, I am not ARM expert at all .. I think this was a quote from somewhere 'In this game maybe it's good we make a few early mistakes, as this relieves us of the pressure of trying to maintain an undefeated record' It is nice to see that the qualities which attracted me to the Maemo project - owning up to making mistakes, correcting them and moving on with our lives - are being carried over to these lists Regards -- http://ianlawrence.info ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion
Hi, ext Jeremiah Foster wrote: On Oct 27, 2010, at 07:07, jarmo.k...@nokia.commailto:jarmo.k...@nokia.com jarmo.k...@nokia.commailto:jarmo.k...@nokia.com 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 [ar...@linux.intel.com] 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 MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion
On 26/10/10 10:18 PM, ext Quim Gil quim@nokia.com 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. fp 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. 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. My take on this as a Nokia MeeGo architect is that we need hardfp. That is where the market is going: Harmattan and linaro are already in that train. IMO, we should start building softfp and hardfp for a 6 months grace period. Once 1.2 is out we should drop softfp. -sakari -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion
On Wednesday, 27 de October de 2010 09:51:44 sakari.pou...@nokia.com wrote: My take on this as a Nokia MeeGo architect is that we need hardfp. That is where the market is going: Harmattan and linaro are already in that train. IMO, we should start building softfp and hardfp for a 6 months grace period. Once 1.2 is out we should drop softfp. I've received a new report from our Technology Management people this morning. The recommendation, in summary, is to use: 1) single-precision floating point (float, not double) 2) ARM's RunFast mode (i.e., not fully IEEE754 compliant) 3) hardfp argument passing 4) disable use of short vector mode On the Cortex-A8, single precision FP with RunFast mode executes on the pipelined Neon core (even if you don't use Neon instructions), which results in single-cycle operations for multiply-accumulate. Anything else will execute in the VFPlite core, which is not pipelined and will impose delays due to lack of pipelining and branch misprediction. Some applications need IEEE754 compliancy, so turning this back on should be possible. But the OS should start apps in RunFast mode by default. I'm not sure I understand what the short vector mode is. If the compiler is generating such a code, it needs to stop. I've passed this recommendation to the Linaro toolchain team already. I'm not sure how things change if the processor doesn't have Neon (like the Tegra II). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)
Hi, ext Thiago Macieira wrote: On Monday, 25 de October de 2010 17:35:48 Arjan van de Ven wrote: this is me, one of the MeeGo architects, opposing breaking the MeeGo API this lightly. softfp-hardfp is ABI, not API break, re-compile is enough for almost[1] all software. For code using only functions with integer arguments, there's no ABI difference. It's ABI break only if you're using functions taking floating point arguments across library borders. MeeGo's value proposition is about giving a consistent platform to ISVs; and this proposal completely destroys that in image, if not reality. In part this is about reputation and part is about reality; if MeeGo ends up breaking the ABIs all the time, or perceived as breaking ABIs this lightly, why bother with MeeGo at all so yes give me a break. This is why I was wondering why we're not using hardfp *now* for 1.1.0. [1] Firefox doesn't support hard-fp fully yet, I don't know about WebKit. There are patches in Mozilla bugzilla for adding hardfp support into XPCOM (small change), but making JIT hardfp compatible is more work. I.e. for now JIT needs to be disabled with hardfp. Note: On N900 using JIT would be bad decision anyway because it increases browser memory usage significantly i.e. makes it noticeably slower because of increased swapping. We shouldn't be breaking binary compatibility. We shouldn't be softp either. Agree. - Eero ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)
Indeed, Also, the trap should catch the hardfp instructions on devices where missing. /Mats -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Thiago Macieira Sent: den 25 oktober 2010 23:53 To: meego-dev@meego.com Subject: Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification) On Monday, 25 de October de 2010 17:35:48 Arjan van de Ven wrote: this is me, one of the MeeGo architects, opposing breaking the MeeGo API this lightly. MeeGo's value proposition is about giving a consistent platform to ISVs; and this proposal completely destroys that in image, if not reality. In part this is about reputation and part is about reality; if MeeGo ends up breaking the ABIs all the time, or perceived as breaking ABIs this lightly, why bother with MeeGo at all so yes give me a break. 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. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion
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. 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. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)
From: Thiago Macieira [thi...@kde.org] Sent: Tuesday, October 26, 2010 12:52 AM On Monday, 25 de October de 2010 17:35:48 Arjan van de Ven wrote: this is me, one of the MeeGo architects, opposing breaking the MeeGo API this lightly. MeeGo's value proposition is about giving a consistent platform to ISVs; and this proposal completely destroys that in image, if not reality. In part this is about reputation and part is about reality; if MeeGo ends up breaking the ABIs all the time, or perceived as breaking ABIs this lightly, why bother with MeeGo at all so yes give me a break. 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. As I said in earlier thread, this is my fault. I should have undesrtood the signifigance and start that work early enough in MeeGo so we would have had change to get it into 1.1 already. My only defence is that this is pretty new stuff, and for the record, I am not ARM expert at all .. This important e.g. for Qt Opengles, and we have that all over the place, even increasingly in the future. I don't see any other possibility that breaking the ABI now when we acn manage it, and also speak about that openly. Sotimes we make mistakes, and then we need to correct them. Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion
From: Arjan van de Ven [ar...@linux.intel.com] 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. 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. and breaking compatibility in an upgrade is even worse than breaking it n a new release... really. 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. Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)
On Tuesday, 26 de October de 2010 16:48:52 harri.hakuli...@nokia.com wrote: As I said in earlier thread, this is my fault. I should have undesrtood the signifigance and start that work early enough in MeeGo so we would have had change to get it into 1.1 already. My only defence is that this is pretty new stuff, and for the record, I am not ARM expert at all .. This important e.g. for Qt Opengles, and we have that all over the place, even increasingly in the future. I don't see any other possibility that breaking the ABI now when we acn manage it, and also speak about that openly. Sotimes we make mistakes, and then we need to correct them. I'm not looking at assigning blame. And from what I hear, even if you had thought of this earlier, we couldn't switch to hardfp now anyway because there are certain software that won't work with it. We need to fix them first. (We just benefit from Harmattan fixing them, since Harmattan has switched to hardfp) Also, the report showing that hardfp was a problem only appeared on my desk about a month ago. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion
Hi, 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. -Jarmo -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext harri.hakuli...@nokia.com Sent: 26 October, 2010 23:50 To: ar...@linux.intel.com; Gil Quim (Nokia-MS/MtView) Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion From: Arjan van de Ven [ar...@linux.intel.com] 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. 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. and breaking compatibility in an upgrade is even worse than breaking it n a new release... really. 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. Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)
Hi all! Comments inline. Am Sonntag, 24. Oktober 2010, 20:44:37 schrieb Carsten Munk: Liberally forking this thread so we can start a discussion - could someone involve the ARM toolchain guys too as we should kickstart this work asap? [...] So, in this case I propose that we do that in MeeGo 1.1.1 (or whatever is the right number for MeeGo 1.1 update). Imho, that will be the least painfull way for everybody, especially if we decide and communicate this now. Now the amount of code/applications that needs to be recompiled is still manageable. As well as the number of affected parties. I don't think this can be done at all. this will break all 3rd party apps and components, including codecs, plugins etc etc that's not something that's just ok to do easily or.. well really, ever. I agree that it is problematic, but even Linaro is moving in that direction which means a lot of reference plugins/codecs on ARM side will actually be hardfp in the future instead of softfp. The elephant in the room is the fact that Nokia's Harmattan is moving/has moved to hardfp too and that apps made for 1.1 ARMv7 softfp won't work on 1.2 ARMv7 hardfp. We can build side-by side for a grace period. How exactly we would bootstrap this work and how/when it would/could be included is something that should be discussed, so here's my kickoff in this area to start a conversation: * The idea is to include support for a new architecture in MeeGo, like we would do in case of a MIPS port of MeeGo, ie, bootstrap port is done (Trunk compiled..), people are assigned to take care of bug fixes, build capacity donated, approved by TSG at some point. This would be ARMv7 hardfp, let's call it armv7hfp. Basically ack. This needs to be done in rpm first. So we need to talk to rpm folks and propose a patch. As they're using armv7l we could name it armv7hl (h for hardfloat). Or is there some upstream consent on armv7hfp ? We shouldn't reinvent the wheel and use this too for the toolchain tuple. But then we need to teach rpm how to differ softfloat from hardfloat - obviously we don't want users to mix it. * Organisationally, do we deprecate ARMv7 (softfp) and state it has been replaced with armv7hfp for 1.2? Well, as we've no way to migrate softfp - hard , what else can we do ? We can build for softfp during a grace period to make transition possible. * To do this, technically, we'd have to bootstrap the port like we did with MeeGo ARMv5. Due to the softfp/hard conflict, we cannot reuse any of the ARMv7 binaries. Back then we started with MeeGo ARMv5, we used Fedora ARM to bootstrap a base system. Since there's no hardfp port of Fedora ARM, I propose that we bootstrap using debian hardfp port, debian-armhf, or using Linaro's work in this area with Ubuntu. Having Linaro involved could be a good thing. The reason for this is that rpmbuild and other tools exist for this platform as well and hence we can do a set of binary armv7hardfp RPMs we can use for starting proper OBS compiles of the MeeGo Trunk. The actual initial bootstrap (on whatever base we do it) is not that big issue - I can provide a walkthrough and do the initial set. Support for OBS+RPM tools for armv7hardfp 'architecture' would be needed and potentially qemu-arm support.. IMHO this is the main things to get this up and running: --- * rpm support to handle/differ armv7 hardfloat * proper qemu-arm support for armv7 hardfloat * obs needs own scheduler name for armv7 hardfloat * bootstrap basics on armv7 hardfloat and build distro with hardfloat. Of course this means our 1.1 developer story sucks from a binary compat point of view, but the risk is that we'll be tied forever to softfp instead.. Yes, exactly. Bet we've the tools to do it ! And throwing this in the discussion too: -mfpu=neon or not in MeeGo ARMv7 hardfp? Should we really hardcode this ? I'd opt for foo-neon optimized packages as glibc can figure that out and fetch the right libraries at runtime (vfp or vfp/neon subfolders) ! This will ensure broad board support. Best, Jan-Simon Möller ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)
From: Arjan van de Ven [ar...@linux.intel.com] Sent: Monday, October 25, 2010 4:59 PM On 10/25/2010 4:06 AM, jarmo.k...@nokia.com wrote: Hi, We have discussed about hardfp (and other) support in the toolchain team. Current assumption is that hardfp will be used in MeeGo 1.2. But there are still quite many other things to be agreed also - regarding different compiler options and switches, etc. Those different options are currently investigated and target is to get default settings for them, i.e. what options are used and how. breaking ABI like this goes way beyond the toolchain team. Really. I would expect the TSG to have a lively debate about such ABI breaks and make the final decision... this is not something that is done lightly, since all ISVs are completely impacted by this. Arjan, give me a break, will you. I would like to see Intel opposing that we are proposing to break ABI on ARM side .. You will likely have good laughs instead. Of course this needs to be elevated, and properly communicated as well. Hopefully already on 1.1 release material. Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)
On 10/25/2010 2:33 PM, harri.hakuli...@nokia.com wrote: From: Arjan van de Ven [ar...@linux.intel.com] Sent: Monday, October 25, 2010 4:59 PM On 10/25/2010 4:06 AM, jarmo.k...@nokia.com wrote: Hi, We have discussed about hardfp (and other) support in the toolchain team. Current assumption is that hardfp will be used in MeeGo 1.2. But there are still quite many other things to be agreed also - regarding different compiler options and switches, etc. Those different options are currently investigated and target is to get default settings for them, i.e. what options are used and how. breaking ABI like this goes way beyond the toolchain team. Really. I would expect the TSG to have a lively debate about such ABI breaks and make the final decision... this is not something that is done lightly, since all ISVs are completely impacted by this. Arjan, give me a break, will you. I would like to see Intel opposing that we are proposing to break ABI on ARM side .. You will likely have good laughs instead. this is not Intel opposing this is me, one of the MeeGo architects, opposing breaking the MeeGo API this lightly. MeeGo's value proposition is about giving a consistent platform to ISVs; and this proposal completely destroys that in image, if not reality. In part this is about reputation and part is about reality; if MeeGo ends up breaking the ABIs all the time, or perceived as breaking ABIs this lightly, why bother with MeeGo at all so yes give me a break. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)
On Monday, 25 de October de 2010 17:35:48 Arjan van de Ven wrote: this is me, one of the MeeGo architects, opposing breaking the MeeGo API this lightly. MeeGo's value proposition is about giving a consistent platform to ISVs; and this proposal completely destroys that in image, if not reality. In part this is about reputation and part is about reality; if MeeGo ends up breaking the ABIs all the time, or perceived as breaking ABIs this lightly, why bother with MeeGo at all so yes give me a break. 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. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)
Liberally forking this thread so we can start a discussion - could someone involve the ARM toolchain guys too as we should kickstart this work asap? 2010/10/24 Arjan van de Ven ar...@linux.intel.com: On 10/24/2010 11:13 AM, harri.hakuli...@nokia.com wrote: From: Thiago Macieira [thi...@kde.org] Sent: Saturday, October 23, 2010 6:48 PM Harri: I propose, that we don't specify softfp as the baseline for complience, but rather say that current softfp is temporary phase and we will move to hardfp as soon as possible, potentially in 1.1 update if we will have such a thing. I think that's a bad idea. We can't switch to hardfp without a full binary compatibility break. So it should be done at the new release, 1.2. That also means devices upgrading from MeeGo 1.1 to 1.2 will need a full reinstall/flashing. No applications from any repository or store will survive and need to be recompiled. I think that we are not supposed to break binary compatibility between Meego 1.1 and 1.2 , so breaking at 1.2 is not good option at all ... So, in this case I propose that we do that in MeeGo 1.1.1 (or whatever is the right number for MeeGo 1.1 update). Imho, that will be the least painfull way for everybody, especially if we decide and communicate this now. Now the amount of code/applications that needs to be recompiled is still manageable. As well as the number of affected parties. I don't think this can be done at all. this will break all 3rd party apps and components, including codecs, plugins etc etc that's not something that's just ok to do easily or.. well really, ever. I agree that it is problematic, but even Linaro is moving in that direction which means a lot of reference plugins/codecs on ARM side will actually be hardfp in the future instead of softfp. The elephant in the room is the fact that Nokia's Harmattan is moving/has moved to hardfp too and that apps made for 1.1 ARMv7 softfp won't work on 1.2 ARMv7 hardfp. How exactly we would bootstrap this work and how/when it would/could be included is something that should be discussed, so here's my kickoff in this area to start a conversation: * The idea is to include support for a new architecture in MeeGo, like we would do in case of a MIPS port of MeeGo, ie, bootstrap port is done (Trunk compiled..), people are assigned to take care of bug fixes, build capacity donated, approved by TSG at some point. This would be ARMv7 hardfp, let's call it armv7hfp. * Organisationally, do we deprecate ARMv7 (softfp) and state it has been replaced with armv7hfp for 1.2? * To do this, technically, we'd have to bootstrap the port like we did with MeeGo ARMv5. Due to the softfp/hard conflict, we cannot reuse any of the ARMv7 binaries. Back then we started with MeeGo ARMv5, we used Fedora ARM to bootstrap a base system. Since there's no hardfp port of Fedora ARM, I propose that we bootstrap using debian hardfp port, debian-armhf, or using Linaro's work in this area with Ubuntu. Having Linaro involved could be a good thing. The reason for this is that rpmbuild and other tools exist for this platform as well and hence we can do a set of binary armv7hardfp RPMs we can use for starting proper OBS compiles of the MeeGo Trunk. Support for OBS+RPM tools for armv7hardfp 'architecture' would be needed and potentially qemu-arm support.. Of course this means our 1.1 developer story sucks from a binary compat point of view, but the risk is that we'll be tied forever to softfp instead.. And throwing this in the discussion too: -mfpu=neon or not in MeeGo ARMv7 hardfp? Best regards, Carsten Munk Nokia N900 hardware adaptation maintainer. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
