On 31/08/12 20:03, Crazy Casta wrote:
> 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.
I guess you mean it would solve a lot of headaches for users - but not
for the implementer!
>
> 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;
> }
>
gcc does not (AFAIK) have any way of attaching an attribute to a
statement or statement blocks - only to types, variables and functions.
Obviously Peter is the expert here, but I think I have a good enough
understanding of the paths in gcc to say this is never going to work.
There are several steps where the C code is interpreted, converted to
different tree forms, optimised, re-arranged, re-constructed, optimised
again, and then turned into RTL, optimised again, converted to assembly,
and peephole optimised. There is no way that an "atomic" attribute
would be able to follow a piece of code through this process.
Of course, this particular example is a poor choice because the
statement cannot be implemented atomically anyway.
I think the nearest you could get would be to implement built_in
functions such as __built_in_bis(dst, src) for an atomic "|=".
mvh.,
David
> 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
