When writing microcontroller code in assembler, it's nice to be able to keep some commonly used variables in registers. The 8-bit AVR devices in particular have a nice big set of registers, most of which are rarely used in compiled code. Usually it's a waste of time to write all the code in assembler, though - it's much better to write the non time-critical bits in C, compile them with GCC and then link with the assembly code bits.<\/p>\n
When accessing the register variables from the C code, the natural thing to do is just to make a global register variable:<\/p>\n
register uint8_t frame __asm__ (\"r3\");<\/pre>\nThat has two effects - it allows you do access the variable as if it were a normal variable:<\/p>\n
void initFrame()\r\n{\r\n frame = 0;\r\n}<\/pre>\nAnd it prevents the compiler from using r3<\/code> for something else (though one also has to be careful that the register isn't used by any other linked in libraries, including the C library and the compiler support functions in libgcc).<\/p>\nThe trouble comes when you try to read those register variables. If optimizations are turned on, then the following code might just be an infinite loop:<\/p>\n
void waitForFrame(int frameToWaitFor)\r\n{\r\n while (frame != frametoWaitFor);\r\n}<\/pre>\nThe compiler hoists the read of frame<\/code> outside the loop, and never sees the updates. If frame<\/code> was a normal variable we could fix this just by adding volatile<\/code>, but using volatile<\/code> with a register variable doesn't work. This seems odd until we think about what volatile<\/code> actually means. A read from or write to a volatile<\/code> variable is considered an observable effect (like doing IO) so the compiler won't optimize it away. But the compiler has no concept of a \"read from\" or \"write to\" a register - registers are just used or not used and the optimizations around them are unaffected by the notion of volatile<\/code>.<\/p>\nThere is a reasonably easy and not-too-invasive way to fix this, though, through the use of inline assembly. If you write:<\/p>\n
#define getFrame() ({ \\\r\n __asm__ volatile (\"\" : \"=r\"(frame)); \\\r\n frame; \\\r\n})\r\n\r\nvoid waitForFrame(int frameToWaitFor)\r\n{\r\n while (getFrame() != frametoWaitFor);\r\n}<\/pre>\nThe compiler will treat the \"\"<\/code> as a block of assembly code which writes to r3<\/code> and which has unknown side effects (so that it can't be hoisted out of a loop for example). The code doesn't actually do anything (so the generated code won't be adversely affected) but it essentially provides a read barrier to the register. Unfortunately you can't use getFrame()<\/code> to write back to frame<\/code>, so to increment it for example you have to do frame = getFrame() + 1;<\/code> but that's actually kind of helpful because it makes the possibility of a race condition (for example by an interrupt routine also incrementing frame<\/code> at the same time) more obvious.<\/p>\n","protected":false},"excerpt":{"rendered":"When writing microcontroller code in assembler, it's nice to be able to keep some commonly used variables in registers. The 8-bit AVR devices in particular have a nice big set of registers, most of which are rarely used in compiled code. Usually it's a waste of time to write all the code in assembler, though […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-1125","post","type-post","status-publish","format-standard","hentry","category-computer"],"_links":{"self":[{"href":"https:\/\/www.reenigne.org\/blog\/wp-json\/wp\/v2\/posts\/1125","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.reenigne.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.reenigne.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.reenigne.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.reenigne.org\/blog\/wp-json\/wp\/v2\/comments?post=1125"}],"version-history":[{"count":6,"href":"https:\/\/www.reenigne.org\/blog\/wp-json\/wp\/v2\/posts\/1125\/revisions"}],"predecessor-version":[{"id":1315,"href":"https:\/\/www.reenigne.org\/blog\/wp-json\/wp\/v2\/posts\/1125\/revisions\/1315"}],"wp:attachment":[{"href":"https:\/\/www.reenigne.org\/blog\/wp-json\/wp\/v2\/media?parent=1125"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.reenigne.org\/blog\/wp-json\/wp\/v2\/categories?post=1125"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.reenigne.org\/blog\/wp-json\/wp\/v2\/tags?post=1125"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}