Using eight bits to save two bits
Do some inflection points make as much sound as one hand clapping? It seems that way. Why else would so many device manufacturers still use 8- or 16-bit processors, when modern 32- and 64-bit processors blow those parts out of the water?
The answer, of course, is cost. 8-bitters are cheap. Unfortunately, this cost-saving measure comes at a, well, cost — lost productivity.
Engineering time is expensive, and an accurate cost assessment needs to amortize engineering effort over the life of the product. Say you are building a consumer electronics device with a short product life. For every cent you save using an 8-bit processor, you might add a dollar’s worth of engineering time to the bill of materials. Your engineers will end up packing and repacking functions, rewriting code to save every spare byte, and manually editing snippets of generated assembly when they could be (happily) focused on adding innovative features.
Compare this to the 32-bit world, where developers crank out code in a fraction of a time using modern tools, libraries, OSs, and application frameworks. Meanwhile, the guy stuck on the 8-bit project is still debugging his old-fashioned bubble-sort routine…
Someday, 8- and 16-bitters will die, once and for all. Productivity wise, that day will be a true inflection point for developers everywhere. It’s a day I will applaud enthusiastically — with both hands.
Andy Gryc, senior product marketing manager, QNX Software Systems
I encourage you to read all of the posts for the inflection point series; maybe they will inspire you to share your observations. I would love to be able to consolidate different perspectives and lessons learned here. I suspect there are some valuable lessons to be gleaned from comparing such stories.
To make following this series easier (especially as multiple series overlap each other), I am including the index below to previous posts, both for this and the guest post channels.
Guest posts:
2010, February 22: Blurring Lines Between 8- and 32-bit Microcontrollers?
2010, February 15: Wireless Everywhere and Programmable Designs
2010, February 8 : Wireless baseband inflection point – SDR as a technological breakthrough
2010, February 1 : Of Windows, Newton’s, iPad’s and 10GBASE-T
2010, January 28 : Technology inflections : digital signal processing
Posts made here
2010, February 22: Inflection Points : Blurring 8- and 32-bit Microcontrollers
2010, February 15: Inflection Points : Wireless and Programmability
2010, February 8 : Inflection Points : Wireless and SDR
2010, February 1 : Inflection Points : timeline (networking)
2010, January 28 : Inflection Points : timeline
2010, January 26 : Inflection Points
Al Sledge commented:
Chris Calver's ideas point to the tip of the iceburg. We mass produce in units of less than 10 (usually 3!). These of course are very specialized, used in very unique aircraft applications. To debounce a few switches or handling serial data streams does not require 32 bits processors. In addition the 32bit development software and emulators are not cheap. In the 8bit world these tools are so cheap even I can buy them. Another player in the multitask world is the "free lunch" idea where multitasking saves hardware costs, but the real cost however can be processor overload, blown stacks, etc. If I have 10 tasks to run it would seem far cheaper to use 10 micros as opposed to 1 multitasker running at 10 times the speed (plus more for the operating system overhead). Anyway those are my ideas and they must mean something or else they would not be paying me the big bucks they do just so I can have fun at work.
Chris Calver commented:
This theory fails to take into account the energy consumption of these larger processors and their associated peripherals. Not all systems have that power to spare - especially battery powered devices. In this age of rising energy costs, it would be irresponsible to use 32 and 64 bit machines for a toaster that 4 bits can control far more elegantly. Also many control functions are already supported by full libraries of code, so not much engineering effort needed there! Unfortunately the 36/64 bit supporters fail to take into account the increased failure rate of the masses of code needed to turn on a light switch with their machines! Come on guys it is still horses for courses and perfect code has yet to be developed!
