Re: modification to inline asm + 128 bit cop2 register support

[Dylan_S_Cuthbert at hq dot scei dot sony dot co dot jp]

Your e-mail and mine are both correct and I don't disagree with any of your
points, but in the same light, my points are valid too.  The difference is that
you are talking from the point of view of someone who has experience porting
gcc, knows the inner-workings and can make substantial changes without
flinching.

Whereas, I'm talking from the point of view of the end-user, who has no
experience of gcc's internals, has no time to compile/test the gcc source and
more importantly would have to re-implement/merge the patch every time the
compiler is updated at the source.

Not everyone is in such a convenient position and with new compiler update
releases every month (in my case), having to make the kind of machine
description patch you're talking about becomes a complete nightmare with regards
to future support.  I work in the video games industry which has extremely tough
deadlines and very short turn-arounds, we have to write an enormous amount of
code (I think you'd be surpised how many lines of code an average video-games
programmer writes in a single week), which has to be incredibly optimized (we
have to synchronise everything to 60Hz), and as close-to-the-metal as possible.

I agree, the %A feature is a short-term solution, but it would *really* help
those of us who have to wait years to see machine-dependent features implemented
by the vendor.

It doesn't make sense to leave the operand "alternative" functionality so
half-assed.  You might as well delete the functionality completely for MIPS
users, which seems a bit mean.

Best Regards
Dylan Cuthbert
(views are mine, no copying!)

PS. Regarding compiler built-ins.  As far as I can see there is no difference
between a compiler built-in and an inline asm function?  Surely the inline
function is the more flexible route (short to medium term)?