Re: Optimisation mixes up registers in inline assembly

David Brown <[email protected]> Wed, 24 Jul 2019 23:30:00 +0200
Newsgroups gmane.comp.hardware.avr.gcc
Message-ID <[email protected]>
Hi,

Inputs to inline assembly are not exactly like references either, 
because they don't have to come from variables already in registers. 
They can be initialised by expressions, data in memory, etc.  They 
simply ask the compiler to ensure that it finds a suitable register (or 
memory address, for "m" constraints) and makes sure that the value that 
is in the input expression is in that register before the inline 
assembly starts.  So it is unnecessary to write "const uint_t one = 7;" 
and use "one" in the inline assembly input value - it would be fine to 
use "7" directly.  Of course, using the named constant can make the code 
clearer and easier to maintain, which is always a good thing.

(Inline assembly inputs are closer to C++ rvalue references, given that 
the inline assembly can modify the registers as it wants.  If it were a 
C++ const lvalue reference, that would not be allowed.)

mvh.,

David


On 24/07/2019 22:44, Joseph C. Sible wrote:
> That's not a very good analogy, as it's really a "reference" in both 
> cases. Rather than value vs. reference, think const vs. non-const. When 
> you only mark something as an input, you're effectively making it a 
> const reference, so the compiler will make optimizations that rely on 
> you not changing it (such as combining it with other things that happen 
> to be equal to it). When you make it an output too, you're effectively 
> making it a non-const reference.
> 
> Joseph C. Sible
> 
> 
> On Wed, Jul 24, 2019, 15:41 Michael Kwasnicki <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     So the inputs to inline assembly are by value and not by reference,
>     as I thought. Right?
>     The correlation between my named registers and those C variables was
>     pure coincidence.
>     And by making the named registers both - input and output - it
>     creates a reference to the original C variable.
> 
>     Regards,
> 
>     Michael K.


_______________________________________________
AVR-GCC-list mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list