Wednesday, October 01, 2014

Forth and the Minimalist

Not all Forth programmers are minimalists, but chances are, if you use arrayForth, colorForth or something inspired by it (like MyForth), then you may be a minimalist.

Being a minimalist, you seek the simplest, most concise use of resources.  You tend to avoid rambling code and the idea of calling a (3rd party) library function makes you uncomfortable.

One of the reasons I like using MyForth (and the 8051) is that it forces you to think about how to simplify the problem you are trying to solve.  This is a good exercise but also offers some advantages when you are working on low power (or very tiny) embedded systems.  No matter how beefy an MCU can get, there is always a need for something "smaller" and lower power (e.g. a tiny low transistor count 8 bit MCU has more chance running off of "air" than a 32 bit fast, feature rich MCU).

The 8051 has rather poor math capabilities. Everything is geared toward 8 bits. If you use a C compiler, this is hidden from you.  The compiler will generate a ton of code to make sure that your 16 or 32 bit math works. This causes code bloat and will slow you down -- thereby causing more power consumption.  Programming in a minimalist Forth makes you think about whether or not you actually need the math.  Is  there a cheat?  You look at old school methods and you may find them. I grew up on the 6502 (Commodore VIC20/C64, Atari, Apple, etc).  You did all you could to avoid doing "real" math (especially if it broke the 8 bit barrier).  You had limited resources and you made the most of what you had.

But, is this just an "exercise"?  I don't think so. There are practical benefits that go beyond just old school cleverness. You (can) have more compact code that performs better. The less code you produce, the fewer chances for bugs. The less code you produce, the more reliable your product.

Gone are the days (for most of us) of penny counting the costs of components. I'd rather have a bunch of simple components (e.g. logic gates, simple MCU, peripheral processors etc) that do work for me rather than a big processor with a complex library.  Chip components tend to be "coded" at a higher level of quality assurance than pure libraries.  I trust a USB->serial chip more than some USB->serial library for my MCU. If the library fails, they say "update". If a chip fails... they risk going out of business -- who trusts production runs to faulty chips?

In the end, the minimalist is fighting the status quo.  It is a futile fight, but we can't seem to give it up. It is in our nature.