From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.dream-property.net ([82.149.226.172]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1SJnv9-0008Gq-9I for openembedded-core@lists.openembedded.org; Mon, 16 Apr 2012 17:32:51 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.dream-property.net (Postfix) with ESMTP id 82072315B29F for ; Mon, 16 Apr 2012 17:23:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.dream-property.net Received: from mail.dream-property.net ([127.0.0.1]) by localhost (mail.dream-property.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aeg38QPLgbBi for ; Mon, 16 Apr 2012 17:23:21 +0200 (CEST) Received: from [192.168.2.108] (p5B119AE4.dip.t-dialin.net [91.17.154.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dream-property.net (Postfix) with ESMTPSA id 144C8315B29C for ; Mon, 16 Apr 2012 17:23:21 +0200 (CEST) Message-ID: <4F8C3968.5040603@opendreambox.org> Date: Mon, 16 Apr 2012 17:23:20 +0200 From: Andreas Oberritter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: openembedded-core@lists.openembedded.org References: <4F847380.6000401@windriver.com> <4F8489DE.1050905@opendreambox.org> <4F8C24CB.3080607@opendreambox.org> <4F8C2EA9.5090100@windriver.com> In-Reply-To: <4F8C2EA9.5090100@windriver.com> Subject: Re: MIPS vs MIPS32 tunings -- summary and questions X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 15:32:51 -0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 16.04.2012 16:37, Robert Yang wrote: > > > On 04/16/2012 09:55 PM, Andreas Oberritter wrote: >> On 10.04.2012 21:28, Andreas Oberritter wrote: >>> On 10.04.2012 19:53, Mark Hatle wrote: >>>> We still do not have a clean answer for how to resolve the concerns in >>>> the recent thread "conf/machine/include: Cleanup MIPS tunings to match >>>> README". The following is in response to a request I received to >>>> summarize the discussion so far, and include the options to resolve the >>>> issue for the current OE-Core release. >>>> >>>> If you are interested in this, please be sure to read until the end >>>> before commenting. >>>> >>>> Background: >>>> >>>> About 2 weeks ago, in response to a number of patches sent for PowerPC >>>> issues, I set to the task of documenting and cleaning up the various >>>> tune files. It was discovered that since they were originally >>>> implemented, a number of minor conflicts and defects had crept into the >>>> system. The recent patch set added a number of README files and >>>> attempted to resolve any duplication, or confusion between items. >>>> >>>> During this work it was discovered that there were two tunings that >>>> produced the same package architecture: >>>> >>>> mips (tune), optimized for mips1 - o32 ABI, produced packages with a >>>> "mips" arch >>>> >>>> mips32 (tune), optimized for mips32 - o32 ABI, produced packages also >>>> with a "mips" arch. >>>> >>>> While "mips1" should work on a "mips32" system, the reverse is not >>>> true. There was no way to distinguish, in a package feed, the >>>> difference between the two sets of binaries. >>>> >>>> I updated the MIPS tune files to resolve this issue. The result was: >>>> >>>> mips (tune), mips1 - o32 ABI, produced packages with a "mips" arch >>>> >>>> mips32 (tune), mips32 - o32 ABI, produced packages with a "mips32" arch >>>> >>>> This lead to the thread mentioned above. At first there were concerns >>>> that the GNU target arch had changed (from mips to mips32), this was >>>> not >>>> the case. The only change is in the produced package arch names. So >>>> the package feeds and image generation are the only components affected >>>> by this change. >>>> >>>> After various discussion with folks, such as Khem Raj, it is unlikely >>>> that anyone would be using oe-core with a "mips1" target. There may be >>>> some mips3 or mips4 targets, but we find it highly unlikely based on >>>> our >>>> current experience. Khem suggested resolving this my simply making the >>>> "mips" include mips32 as the default optimization. >>>> >>>> Image generation was verified to produce the same images before and >>>> after this change for the qemumips target. I am unable to verify the >>>> package feeds, as I do not have a suitable setup for this. >>>> >>>> So possible solutions to this particular issue, which we do need on >>>> prior to the upcoming release: >>>> >>>> 1) Revert the behavior and match that last release. We have two tunes >>>> that produce different binaries w/ the same "mips" package arch. >>>> * This preserves previous behavior, but IMHO continues to implement >>>> the defect >>>> >>>> mips (tune) - mips1 processor, o32 ABI - mips package arch >>>> mips32 (tune) - mips32 processor, o32 ABI - mips package arch >>>> >>>> 2) Keep it as it is currently checked in. Provide the ability to build >>>> a basic "mips" and a more optimized "mips32" tuned target and >>>> package set. >>>> * This fixes the defect and provides the opportunity for "mips" >>>> to be >>>> a basic common package arch, while mips32 (or additional mips3? mips4? >>>> mips32r2?) tunes could be used to augment this for specific systems. >>>> >>>> mips (tune) - mips1 processor, o32 ABI - mips package arch >>>> mips32 (tune) - mips32 processor, o32 ABI - mips32 package arch >>> >>> If the tune should reflect the optimization, then mips should be renamed >>> to mips1 and specified explicitly using -march=mips1, in order to >>> protect against changing defaults when using a newer compiler. However, >>> as Phil pointed out, there are many more optimization settings, e.g. -O2 >>> vs. -Os, that aren't encoded into the package arch, so the goal to have >>> distinct package archs for different binaries won't be reached. >>> >>> I don't see what a common "mips" package arch would give us. Within OE, >>> you'd usually compile all your applications for the package arch of your >>> target system. Adding compatible package archs to the feed just >>> increases the complexity of online updates. >>> >>>> 3) Define only one mips tune, with a target package arch of "mips". >>>> Changing the basic mips tune, and corresponding mips package arch to >>>> include mips32 optimizations and instructions. >>>> * This preserves the "mips" tune, but changes the behavior of the >>>> tune from default compiler, to mips32 optimization >>>> * Anyone requiring mips3 or mips4 will need to add a tune, and that >>>> tune will not be compatible with "mips" >>> >>> Also, mips1 could be added back anytime if anybody starts using it. >>> >>>> mips (tune) - mips32 processor, o32 ABI - mips package arch >>>> >>>> 3a) Preserve the mips32 tune entries, but define it as being >>>> equal to >>>> mips >>>> * Preserves the tune entries for compatibility, but is anyone >>>> directly using them? >>>> >>>> 3b) Remove the mips32 tune entries -- effectively eliminating mips32 >>>> as a tune >>>> * Removes the tune entries (cleans up the tunes), no >>>> compatibility >>>> -- but it's unlikely anyone was directly specifying "mips32" as their >>>> machine's DEFAULTTUNE. >>> >>> Actually I have (had) machines specifying mips32el and mips32el-nf as >>> their DEFAULTTUNEs, which your first patch, that got applied upstream, >>> broke. But I've already switched to use your latest patch using mipsel >>> and mipsel-nf instead, (which I prefer over the former). >>> >>>> My recommendation is either 2 or 3. The 3a/b variation is simply an >>>> implementation detail to me, and I will be happy to implement it either >>>> way if this is the chosen direction. >>> >>> I'm fine with either way that restores mips/mipsel for mips32 targets >>> *before the release*, because the online update feeds broke and all >>> packages had to be built again from scratch. >> >> Richard, can you please state your opinion about this issue? >> >> The mips package feed (e.g. qemumips) is now broken since weeks. Can I > > I'm a little confused with this, I've just done a build with > MACHINE = "qemumips", both build and runqemu worked well. The feed arch changed from mips* to mips32*, so online updates broke. Regards, Andreas