[Ffmpeg-devel] Mac OS X Intel last part: balign directives

[John Dalgliesh]

Hello list,

Looking for a bit of direction on this last bit of the patch: problem 
being that Apple's as does not recognise '.balign'. I am aware of previous 
determinations on this issue, e.g.: 
<http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-February/007645.html>


-- Option 1: Replace .balign with .p2align.
I know Michael has said this won't happen. If that decision is final 
please skip to next option. Otherwise please consider these arguments:

Arguments for:
a. Both .balign and .p2align were added to gas simultaneously in 1995: 
<http://sourceware.org/ml/gas2/1995/msg00077.html>. So if you have one you 
are very likely to have the other. Mach's as was forked before then, and 
.p2align was only added in early 2003 by developer request: 
<http://darwinsource.opendarwin.org/10.2.8.G5/cctools-466/as/notes>

b. .p2align is more specific than .balign, and thus the more likely to be 
supported of the two, so it should be used if it can be. .balign sounds 
like it can do any integer alignment.

c. Actually in gas, .balign only supports power-of-two alignments anyway:
binutils-2.17/gas/read.c:1313: 'as_bad (_("alignment not a power of 2"));'

d. .p2align is more popular than .balign:
<http://googlefight.com/index.php?word1=balign&word2=p2align> :)

Non-arguments:
a. other projects have relented and switched to .p2align, e.g.:
<http://lists.xiph.org/pipermail/commits/2006-July/009658.html>

Arguments against:
a. not going to change it arbitrarily just for one broken platform; other 
platforms could support .balign but not .p2align.
b. .balign is (arguably) more readable than .p2align.


-- Option 2: Apple's 'as' is broken, so fix that with a minimally 
intrusive patch.

I have a patch ready that defines an assembler macro to emulate .balign on 
Apple's as. All that is required is that files using .baligns invoke a 
(cpp) macro somewhere near the start of the file, which emits the 
assembler macro. (I could add it to the start of every file in e.g. 
common.h but IMHO that would be bloat since only 3 files require it). The 
definition of the cpp macro would be determined in configure.

I have submitted a bug to Apple to get them to implement .balign: 
<rdar://problem/4673334>, so this code could one day easily be removed. 
(Don't expect anything in the next 6 months 'tho.)


-- Option 3: Both .balign and .p2align are non-standard, so make macros 
for them that expand to correct directive for each platform.

This is the option proposed in February. Initially Apple's as would have 
to be specifically detected in configure, in which case .p2align would be 
used, otherwise it would default to .balign. If support was desired for 
other old/non-GNU assemblers they could be easily added.


OK those are the options as I seem them. Comments anyone? My preference is 
in the order 1, 2, 3. I think 3 is overkill, 'tho I am happy to provide a 
patch for any of them.


Thanks in advance,

{P^/
John

btw. Apologies for sending three messages in a row, but I will be offline 
for the next ~20 hours and want to keep my pipeline full.