dw <limegreenso...@yahoo.com> writes:
>> I think it really is general though. In:
>>> The same problem can occur if one output parameter (@var{a}) allows a
>>> register constraint, is updating the parameter value, and references an
>>> address while another output parameter (@var{b}) allows a memory
>>> constraint.
>
> Yep, you're right. I have trimmed this back to just:
>
> The same problem can occur if one output parameter (@var{a}) allows a
> register constraint
> and another output parameter (@var{b}) allows a memory constraint.
>
> Seems like that's the last of it then. I've updated the web pages
> (http://www.LimeGreenSocks.com/gcc/Using-Assembly-Language-with-C.html)
> if you want to look at how it turned out.
Looks great to me. Just noticed one small nit: in the extended asm
section, "=irm" isn't valid, since you can't assign to an immediate.
Also, in the section about clobbers:
It causes the compiler to flush all registers to memory before
executing the asm statement.
At first I read this as meaning "all registers are saved somewhere in
memory before the asm". Maybe something like "flush all pending stores"?
Not sure whether that's better or not though.
Thanks again for all the work on this.
Richard
