Thursday, December 24, 2009

8 bit processors. Still? Seriously?

Maybe I'm showing my age, but I remember the good old days. The first processor I programmed for was a 6502. Followed by a list of other illustrious 8-bit processors, like the 8088, the Z80, and the 8080. All either in assembly or a mix of assembly and Pascal--remember Borland, anyone? Sometimes assembly and C.  Then came all their 16-bit friends, which were more of the same ilk.  Life was simple then--there wasn't any code in the system that you didn't write.  Total transparency.  And total control.

But the good old days weren't always so good.  The romantic simplicity of those times is overshadowed by the memories of all the hassles and engineering challenges in dealing with those 8-bit dinosaurs.  The constraints on those processors were huge: very little memory, very sparse registers with dedicated functions, and arcane mixes of available instruction/register combinations.  Lots of time packing and repacking functions, rewriting to save every spare byte because the chip couldn't address any more than a squeak of memory.  Making your code impossible to fix or edit, because you had a clever trick to save ten bytes by manually chopping out snippets out of the generated assembly.  Confusingly overloading functions, inexorably linking code for two totally unrelated purposes, like the calculating the display column offset and delaying for proper timing of an A/D read.  You know... in hindsight, those days were truly awful.

Still today, although the 8-bit well has almost dried up, companies are selling and creating products that use 8-bit and 16-bit processors, when 32-bit and 64-bit processors are available.

The answer is easy--cost. 

Unbelievably, it's still cheap to make those antiques.  Either that, or there is just some warehouse in New Jersey that's piled ten stories high with the junk.  Having known how difficult it is to squeeze some life out of these tired old dogs, I can only pray that they just go away for good. 

Because I care about software engineers and their mental health.

The true cost of programming for 8-bits is lost productivity.  Engineering time is not cheap, and although it often isn't considered, an accurate cost assessment needs to amortize engineering effort over the life of the product.  For a consumer electronics device, the life of the product is preciously short, and for every cent you save on using an 8-bit processor, you add a dollar's worth of engineering time to the bill of materials.  In the brave new 32-bit world, productivity is amazing--you can crank out code in a fraction of a time using modern tools, libraries, OSes, and applications frameworks.  32-bit tools can completely blow away what is even possible an 8-bit micro, all the while the other guy is still debugging his old fashioned bubble-sort routine.

For the sake of software engineers everywhere, let 8- and 16-bits die, once and for all.  I'm there for you, you poor non-32-bit engineers.  Until that day.


  1. This comment has been removed by a blog administrator.

  2. I'm also old enough to remember these days. However I don't agree 100% with you. The component that is missing is training, today it takes a lot more time to get someone to be productive and write good code.

    I remember the first machine that we build with a 8086 64K ram, half assembly/C. Program was burning an EEPROM and update send by bus to customers. Took 6 months with 2 programmers to get the first working machine.

    Today a similar machine that does the same basic thing, but of course with extra bells and wissle, all C and C++, with real-time part under QNX6 and the user interface written in JAVA took 4 programmers over 1 years.

    Would I go back, nah, but there is something to learn from that.

  3. My question would be how big the extra "bells and whistles" are--does the new burner allow you to log into a website to control it? Can it handle a host of different formats and burners?My guess is that although the two designs do the same basic thing, that there is a huge amount of functionality that's present in the new design that wasn't in the old design. A typewriter and Microsoft Word can both create a document, but you won't get fonts, images, revision control, etc. from a typewriter. I wouldn't want to write Microsoft word in assembly code for an 8-bit processor, even if it were possible. If you stacked up two exactly equivalent designs, you'd be hard pressed to even implement some newer devices using 8-bits. What 8/16-bit processors did were to give engineers the right to flat-out deny feature creep, which, as you've rightly pointed out, is with us to stay.

  4. Most people complain Microsoft Word is too big anyway ;-) My girlfriend is complaining all the time she can't find the option she wants and she is constantly baffle by its behavior. Yet she insist on use it LOL!