* Nils Holland <n...@tisys.org> wrote:
> The question is, I guess, if the target host, when of the same arch (i.e.
> i[3456]86) does actually have any influence on the code that gets
> generated in terms of performance or ability to run on other sub-arches.
> This is what I really couldn't find out so far and would find highly
> interesting to know.
Yes, both. Passing arguments via register (instead of stack) can be
much faster in some cases, especially when you have a lot of calls
with small parameter sets, eg:
libfoo.c:
int foo(int a, int b)
{
... <do-something> ...
}
progbar.c:
int main()
{
...
for (int x=0; x<10000; x++)
foo(x, wurst);
...
}
On older subarchs, main() will have to push x and wurst on stack for
_each_ call, and foo() has to pop them down. With a newer subarch that
has more usable registers, the parameters a and b can directly sit in
registers (probably the counting of x might already happen in the same
one), so the parameters dont have to go through the stack. That all
heavily depends on the target ABI.
> For example, why not just go (and stay) with CHOST="i386-pc-linux-gnu" and
> on an i686 machine, set march or mcpu = i686 via CFLAGS if you want to
> optimize for the particular subarch at hand? Why should it be necessary /
> what would the (dis)advantages be of of such a setup vs. also having CHOST
> set to "i686-pc-linux-gnu"?
I'm not sure right now if/how -march and -mcpu affect calling convention,
variable alignments, etc (IMHO -march does, while -mcpu doesn't), but
as soon as you change these ABI elements, it can get really dangerous.
> Concering the Gentoo doc about changing the CHOST that was mentioned: Yep,
> I've read that. If I understood it correctly, problems when changing CHOST
> mainly seem to arise because of the way GCC and related basic build utils
> install themselves (using the host triplet as part of their path or
> executable name), leaving wrong / messed up references when changing the
> CHOST.
You're lucky if the compiler fails early this way, so you don't have
the unpleasant experience of sudden runtime breakages ;-p
> For example, as I've said previously, the CHOST value gets passed to
> ./configure as --host for each package that gets build. That would make
> configure try to select a compiler called <CHOST>-gcc in order to compile
... if the toolchain commands aren't passed explicitly ...
(which you *SHOULD* do in any crosscompiling scenario)
> the package, i.e. when CHOST is i486-pc-linux-gnu, a compiler called
> i486-pc-linux-gnu-gcc would be used. Include file directories for glibc
> and / or glibc itself sems to be selected by a similiar mechanism.
AFAIK they're not selected by this parameter (even some illdesigned
configure script might do such crazy things on its own ;-o), but built
into the toolchain commands themselves. You can override/change them,
but then you really should know what you're doing ;-p
> The Gentoo CHOST document that was mentioned says something about nptl not
> being available on i386. If true, and if the host variable generally
> influences the availability of features, things would slowly start to make
> sens as to why the CHOST might be important.
Exactly. nptl vs. linuxthreads is exactly an good example for
incompatible ABIs (while API more or less stays the same).
> On the other hand, I've read
> through some documentation of the GNU C library (glibc) and didn't even
> find anything about nptl not being available on i386, not to mention
> anything else about different features on different subarches.
I don't know much about their internals, but I can easily imagine
that nptl makes heavy use of newer registers which linuxthreads didn't.
For those things you should ask the gcc and libc folks.
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
