Re: [avr-chat] Missed Optimisation ?

[bob]

>> So, I think that the compiler is doing exactly what it should do.
> 
> Have to agree, 'cos the code can break if it doesn't respect a genuine
> volatile.
> 
> Mind you, if "result" is genuinely volatile, then it can change between
> the |= and the >>=, so we could be right shifting the other thread's
> value, couldn't we?
> 
> <$.02>
> Over 25 years I've always written ISRs in assembler. That has made them
> easy to optimise, predictable in behaviour, and independent of compiler
> "improvements" in the event of having to use another version. (Not that
> in-line asm stuff, rather a proper linked-in asm file. Lots easier. ;-)
> Oh, 'n don't have to argue with the compiler about what's "volatile"
> either.
> </$.02>
> 
> Erik
> 
Hi Erik ! (and Graham and Jan and Alex)
I suppose 'big machines' might interrupt in the interrupt (as can the
avr, but it doesn't unless you make it).
In the construct <load value> < OR > <save value>, it just doesn't make
sense to me to cheat on the OR'ing but not on the load/save part.
Your thread argument is true but would be broken by the current compiler
action (e.g. if the value of result was changed externally between load
and OR and save) but then you would never be able to guarantee anything.
I think that, in an interrupt where no other interrupt has been enabled
(i.e. in the interrupt code itself), then it would be better to save
some bytes.
But maybe that's too complicated.
You are right in saying that ISRs are better written in assembler (and
linked), only then do you have 'full control'.
I will do this in assembler anyway, it was just a point I wanted to
discuss with the list - thanks for doing just that.
It still seems to me that cheating on a part of the code, but not the
other part is a bit screwy :-)

Cheers,

Bob