[OE-core] ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te?

[Koen Kooi]

Op 11 sep. 2012, om 17:51 heeft Mark Hatle <mark.hatle at windriver.com> het volgende geschreven:

> On 9/11/12 8:48 AM, Martin Jansa wrote:
>> On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote:
>>> Hi,
>>> 
>>> when building spitz and qemuarm (both produces packages in armv5te feed)
>>> resulting packages are tuned with -mtune=xscale (when built for spitz)
>>> or -mtune=arm926ej-s (when built for qemuarm).
> 
> I argued this when we original did the work for the tunings, and I lost....
> 
>>> From
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5
>>> Firstly, if you go changing the tune parameters in a given machine, you are expected to use a different PACKAGE_ARCH. If you do that, you will get a different package feed for the different binaries, different WORKDIR and so on. This was always the way the package architectures was intended to work and nothing has changed there. Yes, you as the user changing various variables can create inconsistent package feeds. There are 101 ways you can do that, the simple answer is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended.
> 
> That is certainly my expectation.  I'm not sure that the arm926ej-s can produce binaries that are -not- arm5te binaries -- as that seems to be the standard for what an armv5te is.  The xscale on the other hand is capable of having different tuning parameters and had a few additional instructions.  

From a gcc point of view both are the same ISA, but using xscale will take in account the absurdly long pipeline on that SoC.