Go Down

Topic: Replacement for AVR libc ATOMIC_BLOCK macros, now for DUE and other platforms. (Read 9 times) previous topic - next topic

pYro_65

#5
Oct 02, 2012, 04:22 am Last Edit: Oct 02, 2012, 04:24 am by pYro_65 Reason: 1
The fact that it has side effects cause it to work correctly.

If a class only modifies its internal data, it has no side effects and the compiler can optimise it away.

However this class ( or group of classes ) write to external data during destruction, the status register/SREG. More importantly, it reads from an external source marked as volatile ( SREG ) during construction so the compiler is forced to omit instructions.

Coding Badly


I suspect you misunderstood the question.  But it doesn't matter.  The C++ standard states the destructor has to be called and the end of the block.

pYro_65

Yes I didn't quite answer your question, but I'm hoping that I haven't assumed anything with my design. The ATOMIC_BLOCK macros state they cover all exit paths and hopefully this is the same. Please anyone let me know if you think something is not as it should be.

pico

I'll try out your new approach by replacing some of the ATOMIC_BLOCK macros I'm currently using a number of programs. I also recently ported the ATOMIC_BLOCK macros over to G++ for an ARM Cortex3 architecture (Leaflabs Maple board) for my own use -- I'll try to port your approach as well to test portability.

I also agree it would be nice for portability to get an implementation that doesn't rely on a relatively exotic feature of the Gnu compilers.

Also, since the original ATOMIC_BLOCK macros are actually based on a "for" loop under the hood to specify the code block, it would be theoretically possible to inadvertantly place a "break" or "continue" statement in such a block, and the compiler would not pick it up as out of place. Not a biggie in practice, but a bug yours doesn't suffer from.

WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

pYro_65

Cool, if you replace existing ATOMIC_BLOCK macros with my version and you aren't using the safe mode, the compiled size should be the same.

Let me know how it turns out. :)

Go Up