----- Ursprüngliche Nachricht -----
Von: David Brown
Gesendet am: 04 Sep 2012 12:59:15
On 03/09/2012 19:54, JMGross wrote:
>> Mainly that it takes two bytes on the stack. Since you don't know
>> how many nested sections you might have (an atomic block
>> only means it isn't interrupted, but this does not imply that it has to be
>> short or won't call functions), you'll end up with a stack overflow due to
>> the added status register contents.
> You would have to have a truly bizarre structure to have so many nested
> "atomic" blocks to use up stack space of any relevance. And if you are
> that close to overflowing your stack, then any interrupts called outside
> the atomic block will be a much bigger risk.
I don't make assumptions about how much it migh tbe nested. Surely,
255 recursions won't happen, but 1, 2, 3 or 4?
Especially if using library code, you don't know (or don't think of)
what happens inside.
And if you have to live with 128 bytes of total ram, every byte on the stack
counts. (yes, the smallest MSPs have that 'much' ram).
> And in real-world code, atomic blocks are small - the status register is
> not saved on the stack but held in a temporary register.
temporary registers hinder optimization, You don't know how much (from
zero impact to significant, depends on the code).
Also, there is no limit on how large or long an atomic section
might be. Just that it doesn't like being interrupted for some reason.
>From a simple atomic 32bit operation to a complex calculation that
depends on certain things not changing in the state of the system.
>> Also, saving the status register
>> and restoring it, will also restore the content of all other bits, not just
>> GIE.
>True, but that won't matter. Compilers do not usually track the state
>of status bits over a longer range than one instruction pattern.
There's more in the status register than just the status bits.
There are the LPM bits too. Besides CPUOFF, which is of
course never set when the CPU is running, there is the control
for XT1 or DCO. And in 3x/5x family, one of them controls the FLL.
Just overwriting the status register may unintendedly reactivate the
FLL, that might have been deactivated inside the atomic block,
with desastrous results. And the others might have impact on
current consumption.
Well, one could declare it as a coding bug to deactivate the FLL inside
an atomic block, but I prefer not creating dependencies where I can avoid it.
And if the atomic block is a timing calibration function, it might be
necessary.
How does the latest MCPGCC handle this on funcitons with critical
attribute?
>> And finally, at least with MSPGCC 3.2.3, I found situations where the
>> compiler didn't like the status register being changed by the push
>> because of the influence it had on the reference to local variables.
>> (in cases where the optimizer optimized R4 as frame pointer away in
>> favor of R1). I didn't find a way to tell that R1 is changed in the course
>> of the assembly instruction.
> This sounds like an old bug in an old compiler version.
As Peter confirmed, this is normal and intended behavior (and that is
what I thought too). The only thing that could be considered not as bug,
but perhaps as a point for optimization, is the fact that noting R2 as
clobbered register does not force the compiler to rely on R4 as frame
pointer even if it could normally be optimized away in favor of R1.
At least I had no success in trying it (and this was consistent to the
compiler documentation I once got for 3.x)
JMGross
------------------------------------------------------------------------------
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
