Pretty good day...

I am contracting for a friend at the moment.  He is a hardware engineer, and writes all his code in assembly language.  I've learned that portability and re-use are more important than performance in most situations, and have opted to work in C.  Having said that, C compilers can be tweaked for code size or performance, and do a very good job at both (even if there are some surprises).

Today is an excellent example of the power of C over assembly language.  We have a family of products that are HCS08 based (Freescale 8 bit).  We have a legacy product which we were rolling into the new product family, it is HCS12 based (16bit MCU).  The two processors have differing bus architectures and some differences in memory map internally.
The only real change to the product was swapping from a proprietary 1 wire bus to differential RS485.  I just implemented the 485, and our associated protocol, on the HCS08 based platform.  It was quicker to take the 485 C code from the newer designs and add the LCD driver, than to take the assembly language LCD driver, and add an assembly language version of the protocol.  I was surprised I got 90% of the functionality in one day.

There is one other consideration.  "Processor Expert".  This is a tool that Freescale distributes with it's tools, and this does a lot of the bootstrapping for you.  Every new IO I added, the PE would build accessor functions for me.  So to set the RS485 enable, the low level code was buried from me, and the "Bean" had a common interface.  It makes it too easy.  Still this is what we need for an aggressive time to market.  The MCUs show re-use of IP between families.  We have to do the same at our level.

That's twice in as many weeks I've seen an assembly code job be reduced to 1/10th the time by using C instead.