This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]