On Monday, October 03, 2011 19:47:57 Michael LIAO wrote:
> On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger wrote:
> > On Monday, October 03, 2011 18:57:28 Michael LIAO wrote:
> >> Most examples would be related to tools generating code.
> >> 
> >> Suppose you have a software package with several hard-coded fully
> >> optimized assembly file for different targets. Your build system need
> >> to know the current target as well as target ABI to select the correct
> >> assembly file to build it. It even desirable if it includes a simple
> >> script to help generate assembly code (like the one in OpenSSL), you'd
> >> better know the target ABI to prepare proper glue code without
> >> breaking ABI.
> > 
> > hjlu posted examples to the x32 site as to handle this.  the only
> > difference between x86_64 and x32 is the size of the pointers.
> 
> Besides the pointer size, there are other differences like indirect
> branch which need different code sequence on x32 and x64. Indirect
> branch would be used in assembly code (yeah, concrete example would
> valuable here but indirect branch should be used potentially and
> possibly in assembly code.) If the assembly code use indirect branch,
> it needs to know the target ABI and generate/use difference code path.

in terms of asm code, it's still possible to use ifdef's to handle cases where 
you truly need different code paths.

in terms of a tool that generates code itself (like gcc), i'm not sure a 
different tuple would make it any easier.  gcc itself simply adds an abi 
configure flag to control what it supports since the backend shares a lot more 
code than is unique to each abi.

we have precedence here where multiple abi's work with a single tuple, and it 
hasn't been a significant hindrance for them.  adding a new tuple is also not 
something to be done lightly ... a lot of code out there parses tuples, and 
they would need updating.

not that i'm the one to convince here, it's just that you need real data to 
back up proposals that shows pros/cons and why your suggestion ultimately has 
more pros than cons ;).
-mike