I'm just going to throw this out there as an idea. It's an idea for a
change to the compiler that would solve a lot of headaches related to "what
will this compile to" questions.
Add a compiler directive of some sort that says the next assignment
statement must be compiled atomically (|=, &=, +=, -=, /=, *=, etc.) must
be done with an atomic instruction. Obviously /= and *= would fail
automatically because there are no atomic instructions for those on the
MSP430. As for the others, if the compiler can make it atomic, it must do
so, if it can't it must fail with an error describing why it can't make it
atomic. Some examples of what it might look like (sorry I don't have any
idea how to add an attribute to a statement inside a function):
__attribute__(atomic) state |= (state >> 1) & DIRTY_FLAG;
__attribute__(atomic) {
state |= (state >> 1) & DIRTY_FLAG;
}
Again, just want to emphasize, I don't know how practical this is wrt
implementation in gcc. I know it would probably reduce optimization of the
attributed code (which I don't think people would mind much). Just an idea
I wanted to throw out there. I think it would add a lot of confidence to
the developers, because assuming the compiler understands the attribute and
implements it properly, the compiler will fail safe. That is to say, it
will not generate some non-atomic instruction just because it doesn't know
how to make an atomic instruction.
Alex
On Tue, Aug 28, 2012 at 12:05 PM, Peter Bigot <big...@acm.org> wrote:
> On Tue, Aug 28, 2012 at 11:48 AM, JMGross <msp...@grossibaer.de> wrote:
> >
> > I think it's a flaw in the compiler that it doesn't use BIS Rx, &y for
> an |=
> > instruction where the result of the right-side value is in Rx.
> > It only does so if the rvalue is a compile-time constant.
> [...]
> > There is apparently still some room for improvements.
>
> Yes.
>
> > I guess (and it's only a guess) that the compiler will also push
> > parameters on stack by loading them into a register and pushing the
> > register instead of just pushing the immediate value or the
> > memory content to the stack.
>
> No.
>
> I really don't understand why you create and publish fantasies like
> this about things that mspgcc might do poorly but doesn't. "But I
> said it was a guess!" is an unworthy excuse for somebody with your
> reputation.
>
> Since it takes you about thirty seconds to create the FUD and takes me
> significant effort to rebut it, I'm not going to even try. I'll just
> make my annual plea that folks remember: JM's expertise on the MSP430
> itself is unquestioned, but he doesn't know how today's mspgcc works
> and unless things have changed doesn't even use it. You're probably
> best off ignoring what he guesses about how it might behave.
>
> [...]
> > Nobody denied that. Only operations with an rvalue that has no
> > volatile parts could be made atomic. And apparently only constant
> > rvalues lead to an atomic operation with the current compiler version.
>
> Not true. See my previous email for the mechanism by which this is
> done, and run some experiments to see the situations where it's
> successful and where it isn't. If it isn't, look for intervening
> instructions from complex calculation of the RHS that prevent
> recognition of read-modify-write pattern expected by the the peephole
> optimization. It's pretty easy to come up with an example where a
> register RHS is applied in a single instruction even in the current
> compiler, and only slightly harder to trick the compiler into making
> the right choice in other cases too (hint: volatile local variable
> named "rhs").
>
> That the optimization can apply less frequently with 20120406 than
> with 20110716 is unfortunate, but suboptimal code is preferable to
> incorrect code, and mspgcc up through 20110716 managed volatiles
> incorrectly.
>
> Peter
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
