Re: Limited number of asm operands

[Espen Skoglund <esk at ira dot uka dot de>]

[Fergus Henderson]
> On 26-Apr-2001, Geoff Keating <geoffk@geoffk.org> wrote:
>> Espen Skoglund <esk@ira.uka.de> writes:
>> 
>>> Is there a good reason why the number of asm operands is limited to
>>> only 10 (apart from only being able to specify 10 operands [0-9] in
>>> asm input constraints)?  This is terribly annoying when you're trying
>>> to build highly optimized bindings to, e.g., special kernel
>>> interfaces.  It also makes it more inconvenient to do things like passing
>>> a high number of CPP defined constants into the asm construct.
>>> 
>>> The attached patch fixes these problems by allowing up to 30
>>> asm inputs/outputs.
>> 
>> One reason is that we'd have to invent a new syntax, because with your patch
>> %10 means something different to before.

> Is that likely to be a problem in practice?
> Are constructs like %10 used currently?

> If this is really likely to be a significant backwards compatibility
> problem, then I'd like to see a patch now that issued warnings for
> such constructs, e.g.

> 	warning: behaviour of `%10' may change in future versions of gcc:
> 	in this version of gcc, %10 means first parameter followed by `0',
> 	but in future versions of gcc, %10 will mean 10th parameter

Except that gcc currently doesn't work this way.  In output_asm_insn()
one currently does ``c = atoi (p)'' which consumes all digits and
produces an error message if the operand number is out of range.
Looking further down the code, however, it seems that the explanation
of the current behaviour in your warning message was indeed the
intended one.

(I do agree that Andi's labelled arguments are much more fancy,
though.)

	eSk