Why does GCC inline assembler require you to specify input/output both by position and by constraint?

Question

GCC inline assembler requires you to list input and output constraints separately. But then it also requires you to specify "=" before an output constraint, which according to the manual means that "this operand is write-only." No modifier means read-only. Now, there seems to me that there is a subtle difference between read-only/write-only and input/output, and that therefore these are treated differently. But how does gcc practically distinguish between "input" and "read-only" if they are not identical? Are there any cases where one would put an "=" on an input constraint, or omit it on an output constraint? For "+" (both read and written) parameters, is there a difference in putting this parameter in the input vs. the output section? Is there a difference between specifying a parameter as a "+" constraint vs. specifying it as follows?

"some instruction" : "=r" : 0 :

Answer 1

The texinfo manual for gcc-4.7.2 states that the '=' is mandatory for output constraints, and that '+' in an output operand means that it could also be an input. The rules are somewhat complex, read the manual carefully.

As I understand it, '=' on an input makes no sense (a written only input?!). If an input is modified, list it as output (there might be several!), perhaps associating it to a junk variable, and tie it with the output by a number constraint.

Yes, this is all rather confusing. The constraints come from the internal language GCC uses to describe operations, and have evolved over time (with some backwards compatibility thrown it for spice). Adopt some style, and stick to it. Remember that the compiler treats your asm() snippet as a black box, to be copied by replacing arguments where told and nothing else, much like preprocessor macros are handled. It doesn't check if your instruction's addressing modes make sense, if the instructions are for your current machine, nothing. Just text to be macro-exanded and copied into the assembly output. Check carefully that you are saying what you mean (hopefully as liberal as the instruction's addressing modes allow, you don't want the compiler to go through contortions to comply with unneded restrictions; but not allowing something the instruction doesn't handle). Check the generated assembly!