Iteration Vs. Recursion for Printing Integer Numbers to a Character LCD/OLED Display - c++

Question

Question
I am looking for some input on how to optimize printing the digits of an integer number, say uint32_t num = 1234567890;, to a character display with an Arduino UNO. The main metrics to consider are memory usage and complied size. The display is so slow that no improvement in speed would be meaningful and minimum code length, while nice, isn't a requirement.
Currently, I am extracting the least significant digit using num%10 and then removing this digit by num/10 and so on until all the digits of num are extracted. Using recursion I can reverse the order of the printing so very few operations are needed (as explicit lines of code) to print the digits in proper order. Using for loops I need to find the number of characters used to write the number, then store them before being able to print them in the correct order, requiring an array and 3 for loops.
According to the Arduino IDE, when printing an assortment of signed and unsigned integers, recursion uses 2010/33 bytes of storage/memory, while iteration uses 2200/33 bytes verses 2474/52 bytes when using the Adafruit_CharacterOLED library that extends class Print.
Is there a way to implement this better than the functions I've written using recursion and iteration below? If not, which would you prefer and why? I feel like there might be a better way to do this with less resources--but maybe I'm Don Quixote fighting windmills and the code is already good enough.
Background
I'm working with a NHD-0420DZW character OLED display and have used the Newhaven datasheet and LiquidCrystal library as a guide to write my own library and the display is working great. However, to minimize code bloat, I chose to not make my display library a subclass of Print, which is a part of the Arduino core libraries. In doing this, significant savings in storage space (~400 bytes) and memory (~19 bytes) have already been realized (the ATmega328P has 32k storage with 2k RAM, so resources are scarce).
Recursion
If I use recursion, the print method is rather elegant. The number is divided by 10 until the base case of zero is achieved. Then the least significant digit of the smallest number is printed (MSD of num), and the LSD of the next smallest number (second MSD of num) and so on, causing the final print order to be reversed. This corrects for the reversed order of digit extraction using %10 and /10 operations.
// print integer type literals to display (base-10 representation)
void NewhavenDZW::print(int8_t num) {print(static_cast<int32_t>(num));}
void NewhavenDZW::print(uint8_t num) {print(static_cast<uint32_t>(num));}
void NewhavenDZW::print(int16_t num) {print(static_cast<int32_t>(num));}
void NewhavenDZW::print(uint16_t num) {print(static_cast<uint32_t>(num));}
void NewhavenDZW::print(int32_t num) {
if(num < 0) { // print negative sign if present
send('-', HIGH); // and make num positive
print(static_cast<uint32_t>(-num));
} else
print(static_cast<uint32_t>(num));
}
void NewhavenDZW::print(uint32_t num) {
if(num < 10) { // print single digit numbers directly
send(num + '0', HIGH);
return;
} else // use recursion to print nums with more
recursivePrint(num); // than two digits in the correct order
}
// recursive method for printing a number "backwards"
// used to correct the reversed order of digit extraction
void NewhavenDZW::recursivePrint(uint32_t num) {
if(num) { // true if num>0, false if num==0
recursivePrint(num/10); // maximum of 11 recursive steps
send(num%10 + '0', HIGH); // for a 10 digit number
}
}
Iteration
Since the digit extraction method starts at the LSD, rather than the MSD, the extracted digits cannot be printed directly unless I move the cursor and tell the display to print right-to-left. So I have to store the digits as I extract them before I can write them to the display in the correct order.
void NewhavenDZW::print(uint32_t num) {
if(num < 10) {
send(num + '0', HIGH);
return;
}
uint8_t length = 0;
for(uint32_t i=num; i>0; i/=10) // determine number of characters
++length; // needed to represent number
char text[length];
for(uint8_t i=length; num>0; num/=10, --i)
text[i-1] = num%10 + '0'; // map each numerical digit to
for(uint8_t i=0; i<length; i++) // its char value and fix ordering
send(text[i], HIGH); // before printing result
}
Update
Ultimately, recursion takes the least storage space, but is likely to use the most memory.
After reviewing the code kindly provided by Igor G and darune, as well as looking at the number of instructions listed on godbolt (as discussed by darune and old_timer) I believe that Igor G's solution is the best overall. It compiles to 2076 bytes vs. 2096 bytes for darune's function (using an if statement to stop leading zeros and be able to print 0) during testing. It also requires less instructions (88) than darune's (273) when the necessary if statement is tacked on.
Using Pointer Variable
void NewhavenDZW::print(uint32_t num) {
char buffer[10];
char* p = buffer;
do {
*p++ = num%10 + '0';
num /= 10;
} while (num);
while (p != buffer)
send(*--p, HIGH);
}
Using Index Variable
This is what my original for loop was trying to do, but in a naive way. There is really no point in trying to minimize the size of the buffer array as Igor G has point out.
void NewhavenDZW::print(uint32_t num) {
char text[10]; // signed/unsigned 32-bit ints are <= 10 digits
uint8_t i = sizeof(text) - 1; // set index to end of char array
do {
text[i--] = num%10 + '0'; // store each numerical digit as
num /= 10; // its associated char value
} while (num);
while (i < sizeof(text))
send(text[i++], HIGH); // print num in the correct order
}
The Alternative
Here's darune's function with the added if statement, for those who don't want to sift through the comments. The condition pow10 == 100 is the same as pow10 == 1, but saves two iterations of the loop to print zero while having the same compile size.
void NewhavenDZW::print(uint32_t num) {
for (uint32_t pow10 = 1000000000; pow10 != 0; pow10 /= 10)
if (num >= pow10 || (num == 0 && pow10 == 100))
send((num/pow10)%10 + '0', HIGH);
}

Answer 1

For a smaller footprint you can use something like this:
void Send(unsigned char);
void SmallPrintf(unsigned long val)
{
static_assert(sizeof(decltype(val)) == 4, "expected '10 digit type'");
for (unsigned long digit_pow10{1000000000}; digit_pow10 != 0; digit_pow10 /= 10)
{
Send((val / digit_pow10 % 10) + '0');
}
}
This produces around 70 instructions - which is about ~14 instructions less then using a buffer and iterating the buffer after. (Also the code is a lot simpler)
Link to godbolt.
If leading zero's is unwant'ed then an if clause can avoid that fairly simpel - something like:
if (val >= digit_pow10) {
Send((val / digit_pow10 % 10) + '0');
}
But it will cost some extra instructions (~9) though - however the total is still below the buffered example.

Answer 2

Try this one. My avr-gcc-5.4.0 + readelf tells that the function body is only 138 bytes.
void Send(uint8_t);
void OptimizedPrintf(uint32_t val)
{
uint8_t buffer[sizeof(val) * CHAR_BIT / 3 + 1];
uint8_t* p = buffer;
do
{
*p++ = (val % 10) + '0';
val /= 10;
} while (val);
while (p != buffer)
Send(*--p);
}

Answer 3

interesting experiment.
unsigned long fun ( unsigned long x )
{
return(x/10);
}
unsigned long fun2 ( unsigned long x )
{
return(x%10);
}
int main ( void )
{
return(0);
}
does/can give with an apt-got toolchain:
00000000 <fun>:
0: 2a e0 ldi r18, 0x0A ; 10
2: 30 e0 ldi r19, 0x00 ; 0
4: 40 e0 ldi r20, 0x00 ; 0
6: 50 e0 ldi r21, 0x00 ; 0
8: 0e d0 rcall .+28 ; 0x26 <__udivmodsi4>
a: 95 2f mov r25, r21
c: 84 2f mov r24, r20
e: 73 2f mov r23, r19
10: 62 2f mov r22, r18
12: 08 95 ret
00000014 <fun2>:
14: 2a e0 ldi r18, 0x0A ; 10
16: 30 e0 ldi r19, 0x00 ; 0
18: 40 e0 ldi r20, 0x00 ; 0
1a: 50 e0 ldi r21, 0x00 ; 0
1c: 04 d0 rcall .+8 ; 0x26 <__udivmodsi4>
1e: 08 95 ret
00000020 <main>:
20: 80 e0 ldi r24, 0x00 ; 0
22: 90 e0 ldi r25, 0x00 ; 0
24: 08 95 ret
00000026 <__udivmodsi4>:
26: a1 e2 ldi r26, 0x21 ; 33
28: 1a 2e mov r1, r26
2a: aa 1b sub r26, r26
2c: bb 1b sub r27, r27
2e: ea 2f mov r30, r26
30: fb 2f mov r31, r27
32: 0d c0 rjmp .+26 ; 0x4e <__udivmodsi4_ep>
00000034 <__udivmodsi4_loop>:
34: aa 1f adc r26, r26
36: bb 1f adc r27, r27
38: ee 1f adc r30, r30
3a: ff 1f adc r31, r31
3c: a2 17 cp r26, r18
3e: b3 07 cpc r27, r19
40: e4 07 cpc r30, r20
42: f5 07 cpc r31, r21
44: 20 f0 brcs .+8 ; 0x4e <__udivmodsi4_ep>
46: a2 1b sub r26, r18
48: b3 0b sbc r27, r19
4a: e4 0b sbc r30, r20
4c: f5 0b sbc r31, r21
0000004e <__udivmodsi4_ep>:
4e: 66 1f adc r22, r22
50: 77 1f adc r23, r23
52: 88 1f adc r24, r24
54: 99 1f adc r25, r25
56: 1a 94 dec r1
58: 69 f7 brne .-38 ; 0x34 <__udivmodsi4_loop>
5a: 60 95 com r22
5c: 70 95 com r23
5e: 80 95 com r24
60: 90 95 com r25
62: 26 2f mov r18, r22
64: 37 2f mov r19, r23
66: 48 2f mov r20, r24
68: 59 2f mov r21, r25
6a: 6a 2f mov r22, r26
6c: 7b 2f mov r23, r27
6e: 8e 2f mov r24, r30
70: 9f 2f mov r25, r31
72: 08 95 ret
Answered one of my questions, 78 instructions for the division function. Also it returns both the numerator and denominator in one call something that could be taken advantage of if desperate.
unsigned int fun ( unsigned int x )
{
return(x/10);
}
unsigned int fun2 ( unsigned int x )
{
return(x%10);
}
int main ( void )
{
return(0);
}
gives
00000000 <fun>:
0: 6a e0 ldi r22, 0x0A ; 10
2: 70 e0 ldi r23, 0x00 ; 0
4: 0a d0 rcall .+20 ; 0x1a <__udivmodhi4>
6: 86 2f mov r24, r22
8: 97 2f mov r25, r23
a: 08 95 ret
0000000c <fun2>:
c: 6a e0 ldi r22, 0x0A ; 10
e: 70 e0 ldi r23, 0x00 ; 0
10: 04 d0 rcall .+8 ; 0x1a <__udivmodhi4>
12: 08 95 ret
00000014 <main>:
14: 80 e0 ldi r24, 0x00 ; 0
16: 90 e0 ldi r25, 0x00 ; 0
18: 08 95 ret
0000001a <__udivmodhi4>:
1a: aa 1b sub r26, r26
1c: bb 1b sub r27, r27
1e: 51 e1 ldi r21, 0x11 ; 17
20: 07 c0 rjmp .+14 ; 0x30 <__udivmodhi4_ep>
00000022 <__udivmodhi4_loop>:
22: aa 1f adc r26, r26
24: bb 1f adc r27, r27
26: a6 17 cp r26, r22
28: b7 07 cpc r27, r23
2a: 10 f0 brcs .+4 ; 0x30 <__udivmodhi4_ep>
2c: a6 1b sub r26, r22
2e: b7 0b sbc r27, r23
00000030 <__udivmodhi4_ep>:
30: 88 1f adc r24, r24
32: 99 1f adc r25, r25
34: 5a 95 dec r21
36: a9 f7 brne .-22 ; 0x22 <__udivmodhi4_loop>
38: 80 95 com r24
3a: 90 95 com r25
3c: 68 2f mov r22, r24
3e: 79 2f mov r23, r25
40: 8a 2f mov r24, r26
42: 9b 2f mov r25, r27
44: 08 95 ret
22 lines, 44 bytes for the divide. also interesting. Might be taken advantage of at the C++ level to save space (if this display loop is the only place you do a divide/modulo).
of course the optimizer knows that the library function does both result and remainder:
unsigned long fun ( unsigned long x )
{
unsigned long res;
unsigned long rem;
res=x/10;
rem=x&10;
res&=0xFFFF;
rem&=0xFFFF;
return((res<<16)|rem);
}
int main ( void )
{
return(0);
}
00000000 <fun>:
0: cf 92 push r12
2: df 92 push r13
4: ef 92 push r14
6: ff 92 push r15
8: c6 2e mov r12, r22
a: d7 2e mov r13, r23
c: e8 2e mov r14, r24
e: f9 2e mov r15, r25
10: 2a e0 ldi r18, 0x0A ; 10
12: 30 e0 ldi r19, 0x00 ; 0
14: 40 e0 ldi r20, 0x00 ; 0
16: 50 e0 ldi r21, 0x00 ; 0
18: 19 d0 rcall .+50 ; 0x4c <__udivmodsi4>
1a: a2 2f mov r26, r18
1c: b3 2f mov r27, r19
1e: 99 27 eor r25, r25
20: 88 27 eor r24, r24
22: 2a e0 ldi r18, 0x0A ; 10
24: c2 22 and r12, r18
26: dd 24 eor r13, r13
28: ee 24 eor r14, r14
2a: ff 24 eor r15, r15
2c: 68 2f mov r22, r24
2e: 79 2f mov r23, r25
30: 8a 2f mov r24, r26
32: 9b 2f mov r25, r27
34: 6c 29 or r22, r12
36: 7d 29 or r23, r13
38: 8e 29 or r24, r14
3a: 9f 29 or r25, r15
3c: ff 90 pop r15
3e: ef 90 pop r14
40: df 90 pop r13
42: cf 90 pop r12
44: 08 95 ret
00000046 <main>:
46: 80 e0 ldi r24, 0x00 ; 0
48: 90 e0 ldi r25, 0x00 ; 0
4a: 08 95 ret
0000004c <__udivmodsi4>:
4c: a1 e2 ldi r26, 0x21 ; 33
4e: 1a 2e mov r1, r26
50: aa 1b sub r26, r26
52: bb 1b sub r27, r27
54: ea 2f mov r30, r26
56: fb 2f mov r31, r27
58: 0d c0 rjmp .+26 ; 0x74 <__udivmodsi4_ep>
0000005a <__udivmodsi4_loop>:
5a: aa 1f adc r26, r26
5c: bb 1f adc r27, r27
5e: ee 1f adc r30, r30
60: ff 1f adc r31, r31
62: a2 17 cp r26, r18
64: b3 07 cpc r27, r19
66: e4 07 cpc r30, r20
68: f5 07 cpc r31, r21
6a: 20 f0 brcs .+8 ; 0x74 <__udivmodsi4_ep>
6c: a2 1b sub r26, r18
6e: b3 0b sbc r27, r19
70: e4 0b sbc r30, r20
72: f5 0b sbc r31, r21
00000074 <__udivmodsi4_ep>:
74: 66 1f adc r22, r22
76: 77 1f adc r23, r23
78: 88 1f adc r24, r24
7a: 99 1f adc r25, r25
7c: 1a 94 dec r1
7e: 69 f7 brne .-38 ; 0x5a <__udivmodsi4_loop>
80: 60 95 com r22
82: 70 95 com r23
84: 80 95 com r24
86: 90 95 com r25
88: 26 2f mov r18, r22
8a: 37 2f mov r19, r23
8c: 48 2f mov r20, r24
8e: 59 2f mov r21, r25
90: 6a 2f mov r22, r26
92: 7b 2f mov r23, r27
94: 8e 2f mov r24, r30
96: 9f 2f mov r25, r31
98: 08 95 ret
Sorry using this space to have fun with this exercise of seeing what a compiler does with this problem. Trying to use the 16 bit division starts to explode register usage burning through the 34 instructions saved.
Because of the fixed denominator and because this is an 8 bit processor you can play optimization games with the compiler, but you may take this down an unreadable path.
Still pretty sure that this can be done tighter without using the division library function and doing it all yourself knowing that this is an AVR. Shifts are brutal though, lots of registers but once you spill over then that explodes the size of the function too. Very delicate.
For the price of one uno you could have bought a handful of blue pills with a lot more of everything, including 32 bit registers and a multiply which turns a divide by 10 into a few instruction. Can still use the arduino sandbox, And runs way faster. (more flash, more ram, compiler friendly instruction set, likely no longer needing to count bytes, should try compiling your project for that target and see how much of the flash is used).