From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13]) by mail.openembedded.org (Postfix) with ESMTP id 8E412711E8 for ; Thu, 28 Aug 2014 14:24:31 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.14.9/8.14.5) with ESMTP id s7SEOVD5012877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 07:24:31 -0700 (PDT) Received: from Marks-MacBook-Pro.local (172.25.36.226) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.174.1; Thu, 28 Aug 2014 07:24:30 -0700 Message-ID: <53FF3B9D.206@windriver.com> Date: Thu, 28 Aug 2014 09:24:29 -0500 From: Mark Hatle Organization: Wind River Systems User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Koen Kooi References: <53F77370.2060603@balister.org> <20140822133349.76751634@e6410-2> <20140822193910.GD20524@jama> <20140822154954.04d4fc02@e6410-2> <20140822214626.GF20524@jama> <20140822170626.13280b11@e6410-2> <20140822222642.GG20524@jama> <53FB8A87.1010202@windriver.com> <53F8A551-7665-45B9-A386-DFA43D57E04F@dominion.thruhere.net> <53FF3565.1030604@windriver.com> <53FF3AE4.6050607@windriver.com> In-Reply-To: <53FF3AE4.6050607@windriver.com> Cc: openembedded-core@lists.openembedded.org Subject: Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon. X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 14:24:31 -0000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Ahh replying to myself.. see below.. On 8/28/14, 9:21 AM, Mark Hatle wrote: > On 8/28/14, 9:08 AM, Koen Kooi wrote: >> >> Op 28 aug. 2014, om 15:57 heeft Mark Hatle het volgende geschreven: >> >>> On 8/28/14, 8:50 AM, Koen Kooi wrote: >>>> >>>> Op 25 aug. 2014, om 21:12 heeft Mark Hatle het volgende geschreven: >>>> >>>>> On 8/22/14, 5:26 PM, Martin Jansa wrote: >>>>>> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote: >>>>>>> On Fri, 22 Aug 2014 23:46:26 +0200 >>>>>>> Martin Jansa wrote: >>>>>>> >>>>>>>> changing >>>>>>>> default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while >>>>>>>> still building with -marm doesn't make much sense to me and is only >>>>>>>> confusing. >>>>>>> >>>>>>> I think the distinction is that if you use armv7at-neon, you *can* build >>>>>>> specific packages with thumb. Mostly, I guess, I don't think it makes sense >>>>>>> to use a tuning that specifically states that it can't run thumb code for >>>>>>> processors which can. Although... May not be an important distinction, really, >>>>>>> as you note. >>>>>> >>>>>>> I don't think it makes sense to use a tuning that specifically states >>>>>>> that it can't run thumb code >>>>> >>>>> The defaulttune is supposed to supply what the processor and ABI are capable of. >>>>> >>>>> So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork. >>>>> >>>>> armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...) >>>>> >>>>> armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.) >>>>> >>>>> So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled. >>>>> >>>>> As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.) >>>> >>>> Again, softfloat != softfp. The current OE default of softfp *does* use the VFP, it just passed the floats in the integer registers. Which is why you will see no difference with hardfloat except for benchmarks and povray. >>>> >>> >>> Exactly. Which is why I haven't recommended to my customers that they -need- the HF ABI, like others in the ARM world seem to be insisting. >>> >>> If you have a LOT of functions that pass floats, or you do it often enough to see the behavior -- I can see how it would be useful. But this is fairly artificial in most of the embedded workloads I'm familiar with. >>> >>> So I'd still say I'd like to change the cortexa* DEFAULTTUNES to reference armv7at or armv7at-neon (continue the softfp ABI for the time being). I'd be fine with the at-neon version, as I think all of the commodity armv7a's have neon. >> >> Thumb1 support has never been stable, so I don't see what it will buy us. It just seems a way to piss of DISTROs without any benefits. >> > > 't' in the tune name indicates thumb of the appropriate version for the part. > > meta/conf/machine/include/arm/feature-arm-thumb.inc: > > TUNEVALID[thumb] = "Use thumb instructions instead of ARM" > ARM_THUMB_OPT = "${@['arm', 'thumb'][d.getVar('ARM_INSTRUCTION_SET', True) == > 'thumb']}" > ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', 't', '', d)}" > ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 't', '', d)}" > ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 't', '', d)}" > ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 't2', '', d)}" > ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7r', 't2', '', d)}" > ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7m', 't2', '', d)}" > > There is a table that actually switches on the right suffix for the part in > question. The -name- ending in a 't' simply means thumb may be enabled. > > Thumb instructions are enabled either within the recipe itself or via the > "ARM_INSTRUCTION_SET" function. > Forgot.. the configuration for each follows: TUNE_FEATURES_tune-armv7a ?= "arm armv7a vfp" TUNE_FEATURES_tune-armv7at ?= "${TUNE_FEATURES_tune-armv7a} thumb" TUNE_FEATURES_tune-armv7a-neon ?= "${TUNE_FEATURES_tune-armv7a} neon" TUNE_FEATURES_tune-armv7at-neon ?= "${TUNE_FEATURES_tune-armv7at} neon" This indicates that you can NOT enable thumb instructions (via the ARM_INSTRUCTION_SET) for the armv7a or armv7a-neon. I think this is a mistake, and part of the reason why I'd like the -defaulttune- to change in this case. (Note, changing the defaulttune will not change what other machine files have set themselves.. it will only change the default for those who have NOT configured something!) --Mark