Re: [m68k 12/13] properly align within code

[Roman Zippel <zippel at linux-m68k dot org>]

Hi,

On Mon, 26 Feb 2007, Jeffrey Law wrote:

> So I'll ask explicitly, can GCC currently generate MOTOROLA_SYNTAX
> assembly code?  If yes, is it broken so badly that anyone trying
> to use it would find it useless?
> 
> If you can answer no to the first question or yes to the second
> question then I won't object to your changes.

Um, your second question depends on your first question being answered 
yes, so I don't know how to resolve this. :)

> If the answer is yes to the first question and no to the section
> question, then I'm going to object to your patch because it 
> changes the code we generate under MOTOROLA_SYNTAX.  THe path
> to getting your patch installed would then be to ensure MOTOROLA_SYNTAX
> will remain unchanged.

That depends on how you define "MOTOROLA_SYNTAX", we never generated pure 
Motorola syntax, integer jump opcodes were always pseudo opcodes.
The only difference might be for fp jump opcodes, which changes e.g. from 
"fbra" to "fjra" and the former is not exact Motorola syntax either as it 
lacks the size argument and that's a bug if you need long jumps.

> > As long as it works nobody will complain...
> Which is precisely why I suggested you could disable it for the
> next release.  If we believe nobody is using it, then disabling
> it should't affect anyone.  You can then remove it the next
> release.

Sorry, but this an exercise in futility. :-(
I'm already quite conservative when it comes to preserving compatibility, 
but you're in whole different league. :-(
There is not a single sign, that this change would break anything. We 
already removed so much with _a_lot_ less fuss. Even at the remote chance 
this breaks anything, the sooner we detect it the better, as we can then
support it properly.
I would understand this if we actually had a significant user base. The 
only active (i.e. visible) users use binutils. I would understand this if 
there would be a significant chance it would break anything. There may be 
some embedded users, but they'll stick to their known working executables 
and they won't randomly upgrade their compiler.
There is absolutely no value in making this more complicating than 
necessary, but there is value in cleaning this code up and making it 
easier to maintain. There is simply more value in making the break now, 
than unnecessarily delay it, so if you want to reject the patch, that's 
fine, but I'm not going to change it either, as it has absolutely _no_ 
value.

bye, Roman