>> LONG LIVE ASSEMBLER - CANNOT BEAT IT FOR PEFORMANCE
I have always wondered if programmers like myself are a dying breed
with the focus on high level languages such as Python, Java, C# and the
variants that have been written within their runtime environments -
but what about good old C and low level assembly programming?
Thankfully, with the surge of IoT and the use of low powered, resource
stricken micro controllers there is a great opportunity for a number of
us to enjoy programming the good old fashioned way - even such that it
is considered that using C is too high level.
Consider the following piece of C to do a shift operation >>
on a 256 bit byte stream:
unsigned char *p, val, carry;
p = (unsigned char *)x;
carry = 0;
for (i=0; i<32; i++) // 32 * 8 = 256 bit
val = p[i];
p[i] = ((val >> 1) & 0x7f) | carry;
if (val & 1) carry = 0x80; else carry = 0x00;
Pretty standard stuff, go through every byte and shift one bit, apply a carry
if applicable and detect if the least significant bit was set to define
the carry status for the next byte. It is completely normal to assume
that when targeting an 8bit Atmel based device such as the arduino - using
8bit code would be the most optimal. Unfortunately, this isn't the case as
you can quite easily see by using the -S compile flag and reviewing
the assembly produced.
The C programming language requires that an int data type
be at least 16 bits in size - so any operations requiring bit wise operations
in C would be done as if they were on 16 bit integers. There are cases
where you can force gcc to use 8 bit - using the -mint8
compile option but it is documented that if you do, you are on your own
and use at your own risk.
In contrast, here is the same code in AVR assembly:
movw r26, r24 ; load x within X (r27:r26)
ldi r18, 32 ; i = 32
clc ; clear carry bit
ld r23, X ; load r23 with value at X
ror r23 ; rotate right r23, with carry
st X+, r23 ; store r23 in X, move to next byte
dec r18 ; loop until r18 is zero
The resulting difference? For starters, the code is much smaller
and so much faster. The ror instruction does all the work
handling the carry logic for us - and since the dec instruction
doesn't affect the carry flag the code is kept to a pure minimum.
When I updated most of my low level "BigInt" functions to assembler,
I saw a speed up improvement of almost two fold.
The bottom line is that when you are dealing with 8bit 16Mhz micro
controllers and there is very limited space to actually write your
applications, you simply need to consider assembly level programming
or your code just wont cut it if you intend to do CPU intensive operations.
On the other hand, it is specific to 8bit processors as the compiler
optimization in gcc for larger sized processors is quite
impressive, which has been in active development for almost every
processor made - dating back to its
back in 22 March 1987.