On 4/9/12 4:30 PM, Phil Blundell wrote:
On Mon, 2012-04-09 at 16:21 -0500, Mark Hatle wrote:
I do, and thus the hell that is ARM. I could not currently generate a single
package feed that work would on a variety of devices (like a traditional
workstaton/server Linux OS would.)
Well, actually, you could in fact do exactly that. What you couldn't
necessarily do with the tunings as they exist right now is generate a
package feed which is optimised for (as opposed to "works on") all those
devices. But it isn't clear to me that you could do that with a
"traditional workstaton/server" kind of distribution either. In the x86
world, for example, the majority of the big distros do not bother to
ship individually-tuned binaries for different processor types,
certainly not for the entire distribution.
Depends on the distribution and reasons for these feeds. What is typical is
that a base distribution will be generated for a common compatible (reasonable)
architecture.. i.e. armv5 -- with specific optimized package (glibc, openssl,
etc) for the target arch, i.e. armv7a. Then you have a couple of packages
hand-tuned for size, speed, or other that define or not thumb and add even a
higher level of optimization. It's possible, folks do it today.. but it's not
always obvious. (I have existing customers today that run a mix like I
described through their own package feed like system. They really don't care at
all that the core system is tuned for a given processor -- they only care that
their specific applications and certain areas are specifically tuned to their
use-cases.) Note, this is not what I would consider a typical use-case!
Add in to that one of the tunings -- not indicated by the package arch
of thumb enabled or not
There are multiple reasons why this isn't indicated by the PACKAGE_ARCH.
Firstly, it's irrelevant: on v5T or newer, the question of whether a
given package is using Thumb-state or not has no ABI impact and there is
no reason for anyone to care at a compatibility level. Second, it may
be unpredictable: the compiler is at liberty (although current versions
of gcc don't exploit this latitude) to switch arbitrarily between
ARM-state and Thumb-state as it sees fit to get the best performance.
And thirdly, it's just another piece of distro policy in the same way as
compiling for -O2 vs -Os (which we also don't encode into PACKAGE_ARCH)
is.
I agree, on ARM the tunings and optimizations between regular and thumb do not
impact the ABI what-so-ever. And so far compilers have to be explicitly set to
do thumb or tranditional ARM mode.. so in the end developers are looking into
the performance and size impacts of each of these configuration and making
changes as they see fit to best meet their needs. These are unique cases
though, the majority of the software built for the core OS uses a single policy
-- it's when something needs to be further optimized that this comes into play.
At this point, I'd "like" to better differentiate the ARM package arches.. I
don't care so much about the thumb enabled or not.. but the other tune settings
are things I do care about. I started to change that for the last update and
decided it was a rat-hole I was not willing to go down at this point. At some
point in the future, I will look at, and document the differences in the tunings
according to GCC configurations -- to get a good idea of what is and isn't
producing the same binaries based on various arch and tune settings.
--Mark
p.
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
