This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH v2 0/10] Tilera (and Linux asm-generic) support for glibc
On 15/11/11 16:14, Joseph S. Myers wrote:
> Heavy limits to what's conditional actually remind me rather of Thumb-1.
> Though with Thumb-1 you can and do move between ARM mode and Thumb mode at
> runtime (and in principle attributes to compile some functions as ARM and
> others as Thumb would make sense) which is not something that makes so
> much sense for 32-bit and 64-bit modes.
So there's more conditional execution than thumb-1 (which was
essentially conditional branches), but a lot less than thumb-2.
> If NEON (Advanced SIMD) is similar to 32-bit, perhaps that (being one of
> the more recent additions to the 32-bit architecture) would be one of the
> more plausible areas for sharing code (possibly sharing generators like
> for Tile rather than generated code).
Again, there's a similar flavour, but the mnemonics are different. Also
the register architecture in the FP/SIMD space is different between
32-bit and 64-bit execution states. We're expecting to keep
compatibility for the vector intrinsics, but not for assembly language
-- another reason not to try to use inline assembly in your code for
doing neon stuff.
> (It would be generically desirable to be able to have a single GCC,
> binutils etc. build supporting multiple targets with a --target= or
> similar option to select between them, whether or not those targets share
> a back end in their implementations. But as I discussed at
> <http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02675.html> that would be a
> lot of work, whereas wrappers round two separate compiler builds are very
> simple - so genuinely multi-target compilers become more relevant if you
> want a single source file to contain functions for different architectures
> - which adds its own complications, although GDB does support different
> call frames being on different architectures.)
>
It's easy enough to produce a generic linker/librarian/objdump; but much
harder for things like the assembler. For the compiler the overlap is
very small -- essentially limited to wanting to share some pipeline
descriptions, but there's no reason why that can't be done without
having to share the entire back-end.
I think genuinely mixed back-ends will have to wait until such time as
the target vector is truly switchable at run time.
R.