Sometimes it really pays to look at the compiler's assembly output... - Page 1
Forum section: electronics / general

author: HwAoRrDk
author_rank: Super Contributor
timestamp: February 22, 2020, 02:54:10 pm
content: Here is a great example of how examining the assembly code generated by your compiler and applying some lateral thinking can benefit both the size and execution speed of some code.I've been writing some code that uses the CAN peripheral of an STM8 micro. I have a CAN message-reception interrupt routine that needs to extract the message ID, length and data of each received message. On the STM8's CAN peripheral, this involves selecting the receive mailbox 'page' of registers, and reading out the aforementioned data from them. Part of this process is determining whether you have a standard or extended ID, and reading from the appropriate registers accordingly (2 of the 4 MIDnregisters for 11-bit std. IDs, all 4 for 29-bit ext. IDs).The first stab I took at the code that reads the message ID from the registers took the following form. Nothing complicated, read each 8-bit value, shift them along, concatenate into a single 32-bit value - ho-hum, just the kind of code you write in your sleep. Just have to remember to mask off the RTR and IDE flags, as they occupy a couple of bits in the first ID register.Code:if(bit_is_set(CAN_RXMB_MIDR1, CAN_RXMB_MIDR1_IDE)) {msg.id = ((uint32_t)(CAN_RXMB_MIDR1 & ~(_BV(CAN_RXMB_MIDR1_RTR) | _BV(CAN_RXMB_MIDR1_IDE))) << 24) | ((uint32_t)CAN_RXMB_MIDR2 << 16) | ((uint32_t)CAN_RXMB_MIDR3 << 8) | CAN_RXMB_MIDR4;} else {msg.id = ((uint32_t)(CAN_RXMB_MIDR1 & ~(_BV(CAN_RXMB_MIDR1_RTR) | _BV(CAN_RXMB_MIDR1_IDE))) << 6) | ((uint32_t)CAN_RXMB_MIDR2 >> 2);}But, examining the assembly output for this code led to a surprise:Code:lda, 0x542aldxl, alda, 0x542aldxh, alda, 0x542bclrwyld(0x18, sp), aclr(0x17, sp)clr(0x16, sp)clr(0x15, sp)lda, xhanda, #0x9fldyl, aldw(0x1b, sp), yclr(0x1a, sp)clr(0x19, sp)lda, xlbcpa, #0x40jreq00104$lda, (0x1c, sp)clrwxclr(0x1a, sp)ldwy, (0x17, sp)ldw(0x15, sp), yclr(0x18, sp)clr(0x17, sp)ora, (0x15, sp)ld(0x01, sp), alda, xlora, (0x18, sp)ld(0x04, sp), alda, xhora, (0x17, sp)ld(0x03, sp), alda, (0x1a, sp)ora, (0x16, sp)ld(0x02, sp), alda, 0x542cldyh, aclrwxswapwxlda, (0x04, sp)ld(0x1c, sp), alda, yhora, (0x03, sp)ld(0x1b, sp), alda, xlora, (0x02, sp)ld(0x1a, sp), alda, xhora, (0x01, sp)ld(0x19, sp), alda, 0x542dclrwyclrwxora, (0x1c, sp)rlwayora, (0x1b, sp)ldyh, alda, xlora, (0x1a, sp)rlwaxora, (0x19, sp)ldxh, aldw(0x07, sp), yldw(0x05, sp), xjra00105$00104$:lda, #0x0600156$:sll(0x1c, sp)rlc(0x1b, sp)rlc(0x1a, sp)rlc(0x19, sp)decajrne00156$ldwx, (0x17, sp)ldwy, (0x15, sp)srlwyrrcwxsrlwyrrcwxlda, xlora, (0x1c, sp)ld(0x18, sp), alda, xhora, (0x1b, sp)ld(0x17, sp), alda, ylora, (0x1a, sp)ld(0x16, sp), alda, yhora, (0x19, sp)ld(0x05, sp), aldwy, (0x17, sp)ldw(0x07, sp), ylda, (0x16, sp)ld(0x06, sp), aOof, that's a lot of code!This won't do, especially as it's in an interrupt handler, which you want to keep as short and quick as possible.So I got to thinking: the layout of the MIDRnregisters is such that, regardless of whether we're dealing with a standard (11-bit) or extended (29-bit) ID, it always has the MSB of the ID in the first register... and the STM8 is a big-endian architecture... Why not just treat the set of registers as one large 32- or 16-bit register? I can alias the first register as a pointer to a uint32_t or uint16_t, and simply read the whole thing in one go!Code:/* In a header file: */#define _SFR16(mem_addr) (*(const volatile uint16_t *)(mem_addr))#define _SFR32(mem_addr) (*(const volatile uint32_t *)(mem_addr))if(bit_is_set(CAN_RXMB_MIDR1, CAN_RXMB_MIDR1_IDE)) {msg.id = _SFR32(&CAN_RXMB_MIDR1) & ~((uint32_t)(_BV(CAN_RXMB_MIDR1_RTR) | _BV(CAN_RXMB_MIDR1_IDE)) << 24);} else {msg.id = (_SFR16(&CAN_RXMB_MIDR1) & ~((uint16_t)(_BV(CAN_RXMB_MIDR1_RTR) | _BV(CAN_RXMB_MIDR1_IDE)) << 8)) >> 2;}Thisdrasticallyshrinks the compiled assembly output:Code:lda, 0x542abcpa, #0x40jreq00104$ldwx, #0x542aldwy, xldwy, (0x2, y)ldwx, (x)lda, xhanda, #0x9fldxh, aldw(0x03, sp), yldw(0x01, sp), xjra00105$00104$:ldwx, 0x542alda, xhanda, #0x9fldxh, asrlwxsrlwxclrwyldw(0x03, sp), xldw(0x01, sp), yWe've gone from 97 instructions to 23. I estimate that, taking into account that the original code was about a 70/30 split between single-cycle and two-cycle instructions, we've chopped about 110 cycles off the overall interrupt code; at a CPU speed of 16 MHz, this saves nearly 7 usec of execution time. Given that the entire ISR executed in approx. 29 usec, that's a significant 24% time saving!So, don't be like me and mindlessly write some naive, inefficient code when all along the endianness of your architecture and register layout were giving big hints about how oneshouldbe doing things.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: February 22, 2020, 05:03:09 pm
content: What -O setting?Tim

author: HwAoRrDk
author_rank: Super Contributor
timestamp: February 22, 2020, 06:21:53 pm
content: None, because the compiler is SDCC and that setting doesn't exist.But to respond to the intent of the question: the default optimisation option for SDCC is 'balanced', and this was with that. Haven't tried compiling the original code with 'speed' or 'size' optimisation levels, but I doubt it would make much difference. SDCC doesn't seem to have as sophisticated an optimiser as GCC.Anyway, I think it's more the difference of approach to the problem that leads to the drastic improvement, rather than any compiler cleverness (or lack thereof).

author: rhodges
author_rank: Frequent Contributor
timestamp: February 22, 2020, 06:41:47 pm
content: I agree 100% When writing STM8 code, I like to browse the assembly listings, mostly with library code, but sometimes even in main code. As you explained, sometimes making changes to your C code will help a lot. And sometimes I decide, "Screw that, I'm using inline assembly so the compiler CAN NOT mess it up."

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 22, 2020, 06:51:44 pm
content: Looking at the generated assembly always pays off for time-critical sections.Now of course things can get particularly inefficient when manipulating 32-bit values on an 8-bitter, and yes the compiler still matters. SDCC seems to be translating your C code pretty "literally" here, whereas a good optimizing compiler would do much better than this. I don't know whether it would do as well as with your hand-modified version, but surely better. Unfortunately, C compilers for 8-bit targets tend to be relatively limited, so I don't have anything better than SDCC available with which I could do some testing...One thing you could try with SDCC is to replace your bit manipulation expression with a struct with bit fields instead. SDCC may compile that more efficiently than manual bit shifting.

author: ajb
author_rank: Super Contributor
timestamp: February 22, 2020, 08:11:24 pm
content: One fine point of what's going on here is that the base register definitions are certainly volatile-qualified, so in the first example the compiler is severely limited in the amount of optimization it can do at any optimization level. The casts to uint32_t in the first snippet in the OP will not necessarily change this, as these are applied after the pointer derefencing built into the register definitions (maybe some compilers will use such a cast as a hint for optimizations that would get around the normal requirements of volatile, but that sounds risky enough that I would want my compiler to NOT do so as a rule). You might be able to get around that by taking the address of the registers and recasting them to non-volatile pointers. It would be interesting to try different variations of that and see what kind of assembly you get.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: February 23, 2020, 01:35:11 am
content: Quote from: HwAoRrDk on February 22, 2020, 06:21:53 pmAh...Sometimes the compiler is smart enough to do things like this; it depends on the internal structure, and how many conditions they put into the optimizer. (GCC and Clang use an intermediate format to reason about optimization, which is then converted to the final target instruction set with little or no additional optimization.)An example where this optimization will fail, might be when the intermediate format has efficient indexed indirect addressing -- access to structs and arrays (and both) are always(??) implemented in literal fashion, using indexed indirect addressing modes when available -- but if the target does not, it will constantly perform pointer arithmetic to deal with the indexing. Of... more historic interest, Z80 and 8086 have some of these modes but they're pretty slow at it (10-20 cycles), so it's not always the fastest route, or the most compact (the instructions are much longer, too).It looks like the STM8 is... 6502-ish? Doesn't have more registers, or many more anyway, but more can be used as pointers? So that'll be a lot of faffing around regardless. Hmm, SP-relative indexed? That's handy.Optimizers also tend to be lazy, so that an operation that they most definitely can improve, they might fail on, just because they run out of time to do it.Last crazy example I made was a bit-shuffling operation; specifically, packing 24-bit color into a 5-6-5 LCD format. I wrote a one-liner (well, one statement, sprawled over half a dozen lines for readability...) and GCC shat out something like 200 words, of what looked to be the expression pretty much verbatim. Much like your first example, just longer. Putting intermediate steps in temp variables cut that by about half.Seems likely, GCC would've improved your particular expression, but clearly SDCC gave up. Probably there's a scale factor where each one gives up, and my example was past GCC's limit, and yours was past SDCC's.Do try the other optimization levels -- those settings sound analogous to -O1 or 2, -O3 and -Os. Maybe they'll use more powerful/aggressive tricks, or just "think" about it for longer.In any case, it's definitely a thing, optimizing code for the target -- ultimately, you're only writing C code for a purpose. When that's specific to a platform, you can write statements that more closely reflect the platform, and should be easier to optimize as a result. (But aren't always. Do keep an open mind to alternatives, and try several when you need to squeeze out those extra bytes/cycles. The compiler certainly isn't as clever as you are, and may not pick up on the approach you were thinking of.)The emphasis on knowing the compiler, and choosing judicious optimization settings, and platform size and performance, reflects the reality -- your time is far more expensive than the chips are, so you rarely if ever have a justifiable reason to optimize this heavily.(I've played with this a few times myself, fortunately I need no justification as I'm not getting paid to code, and with good reason.)And of course for cross-platform code, you can, say, write headers for each platform -- #if _CPU_STM8 ... #elseif _CPU_AVR ... etc. You can always keep a copy of straightforward, well commented, but maybe not terribly optimal, code in the #else clause -- that way your code always works onsomeplatform, but also works particularly well on the enumerated platforms.The challenge then of course being, keep all versions in sync when that code inevitably needs updating.Tim