[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cross-toolchain and x86 target status

>>>>> "Nikita" == Nikita V Youshchenko <yoush@cs.msu.su> writes:

Nikita> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Nikita> P.S.  Another interesting issue is tool naming. How should
Nikita> tools be named: i386-linux-gcc or i586-linux-gcc? And when
Nikita> comes to multilib, should 'i386-linux-gcc -m64' be the way to
Nikita> build for x86_86, or there should be separate
Nikita> x86_64-linux-gcc? And what about binutils? Btw, same issue
Nikita> exists on s390/s390x and on sparc/sparc64.  Looks that a
Nikita> consistent way is to make any compiler capable to build for
Nikita> every compatable target, but to build by default for the
Nikita> target that is in it's name. E.g. i386-linux-gcc by default
Nikita> builds core for i386, i686-linux-gcc builds code optimized for
Nikita> 686, and x86_64-linux-gcc by default builds for x86_64. But
Nikita> all those are several frontends for single compiler binary in
Nikita> gcc-lib/, so 'i386-linux-gcc -m64' could be actually the same
Nikita> as 'x86_64-linux-gcc'.  But I've never seen things done this
Nikita> way, so it probably is not easy, and it's not clear whether it
Nikita> is worth effort or not.
>> The same problem arises for ARM.  gcc can target any of the ARM
>> processors, but fails to be multilib for them, especially wrt
>> big/little endian issues.

Nikita> Are there any ARM big endian CPUs? I've never heared of such

Xscale is biendian; several of the development boards are wired
big-endian, and requre big-endian kernels, libraries etc.
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Reply to: