Does anybody use FORTH for embedded programming?
I wrote a few Palm OS apps with Quartus Forth. It was fun, and learning Forth was a great intellectual workout, but I don't think I'd use Forth again.
As to whether anybody uses it for embedded development, you can check with FORTH, Inc.. They stay in business somehow.
I'd say that Forth is similar to Lisp/Scheme, in that learning it exposes you to ways of thinking that will make you a better programmer, but it is unlikely you are going to make a living using it on real-world projects.
I happen to be a odd bird -- one that loves the Forth language. I have coded in Forth in a embedded system, and on a Ultrasound machine, and a control system for building environments. It has been a while, and I am always looking for applications that are using this language. Unfortunately it's use has been limited. If you get a chance check out Chuck Moore's interview on his newest Forth engine. It will be interesting to see where his newest chip turns up. If you have questions in regards to your embedded app. I would be happy to help when possible. [email protected] -- Hope the spelling is ok
Sun's OpenBoot used Forth in a boot firmware environment. I worked on FCode ethernet drivers to allow the Sparcstation to boot itself over the network.
Apple used the same system in later models of the PowerPC macintosh.
Not for a couple of years.
I did have to work with a very strange forth dialect on some legacy products a few years ago.
And in the past I've used it as an environment for testing and verifying hardware (particularly accessing peripherals while they were still under development). Absolutely fantastic in that environment as it's all self contained, and you don't have to go upgrading firmware every time you want to do something new.
The greatest benefit that I derived from learning FORTH early in my career is the ability to read PostScript. Very similar.
Forth is perfect for writing code running in small microcontrollers. For example, rforth1 targets Microchip PIC 18Fxxx family and generates very efficient native code for those microcontrollers.
Well over twenty years ago I was working in my first job, in a two person embedded development company. One day my boss (the hardware guy) came to me (the straight out of university software guy) and announced he had found the ultimate solution to our software development problems. We jumped in his car and went to visit a company he insisted knew the one true way to avoid all the usual productivity problems. It was an amusing and impressive visit that has stuck in my mind. The company we visited developed very prosaic equipment for gas dispensing and metering applications or somesuch. The cool thing was that all the engineers were apparently barefoot hippies. The uber software god there was about 14 years old, he was actually still a schoolboy, the son of the development boss. I can't remember whether we waited for the son to join the team at 4pm or so that day.
The point of my rambling story was that these guys really could do amazing things, all with Forth. In those pioneer days developing embedded software had some challenges that would be completely foreign to a contemporary developer, used to calling on the resources of a global internet connected community. In those days resources arrived by mail. In my part of the world, you would do something like order a rudimentary cross assembler, and then wait weeks for the product to arrive on a floppy disk. In the meantime you would plan how you were going to debug your app with an oscilloscope. However these Forth guys were way ahead of the game. For example, given a totally new CPU they could wirewrap a rudimentary host system, and roll their own native embedded Forth development system for the new chip, using nothing more than the technical reference manual for that chip, in less than a day. (The innermost primitives only were machine dependent, and they were so few in number that the task was manageable with hand assembled machine code).
Unfortunately at the time I simply didn't have the skill or confidence to pick up their approach and run with it. Years later the company had allowed new product development to whither but were still selling the old products as a cash cow. Someone decided there was scope to do something new with the product line and hired a friend of mine to take a look at the original source code. Last I heard he was busily converting it all to C, which is a shame in a way.
I don't use forth directly but I cannot fail to mention user and system RPL on the HP calculators. I fell in love with user RPL on the HP28x and still love to use it on the HP50.
Hey - it was the only real language available for an Atari 400 at the time. I used it for an on-line videotext (interwhat?) banking application.
Crazy 3D emulator of Jupiter ACE, an ancient Forth based computer...info
Honk Honk!!
I've always thought Forth was a beautiful language. Threaded code is a very powerful idea that seems to have been forgotten somewhere along the way.
Though my favourite threaded interpretive language has to be LOGO (falls into nostalgic reverie about BBC Micros and motorized turtles)
Thanks for reminding me.
I wrote code in FORTH for an embedded system about 15 years ago and really enjoyed it, but nothing since then (it's been C and C++ since, so it's been downhill all the way). I used MPE PC PowerForth by MicroProcessor Engineering Ltd. They're still around, so there must be a market (in the UK at least) for FORTH.
Like most Forthers, I wrote my own Forth. I've been working on it for over fifteen years and although the main language is pretty stable nowadays, I still find ways to optimize the beast and extend its usability. Something rather peculiar has been happening the last few years, in the way that more and more functionality is leaving the main code and being coded into Forth itself, which means the actual compiler is getting SMALLER.
Although the compiler is relatively large (64K) it is pretty complete, including a block editor, C-source generator, IDE and decompiler. I never get over the fact that all this functionality can fit in such a small package! That's really something you only find in Forth.
I still use Forth almost daily, especially since it is so easy to create parsers and conversion programs with. Much easier than e.g. C. The added bonus of writing your own compiler is that if some functionality lacks, you can add it yourself. ;-)
Sure, in those days, where people are unable to do range checks or balance their own malloc() / free() calls, people have very little use for languages that forces them to balance their stacks. Which is a shame.
The only way I can illustrate how powerful Forth is, is by telling you a real life story. One of my Forth programs converted CiscoWorks CSV dumps to SQL scripts. One day they told me the program had ceased to function, because they had upgraded CiscoWorks. It now exported XML files, which are notoriously hard to parse. Within an hour I had written a dedicated Forth program, which interpreted the XML file. Every tag had become a command, so as a matter of fact the XML file had turned into a script that rewrote itself to SQL. I know of no other language that allows you to create a dedicated interpreter so easily.
Not for embedded programming, but it's still among my favorite "knocking around ideas" language and a nice break from the C++ I use for my real job.
BTW, I taught my kid FORTH as one of his first programming languages (even used my old copy of Starting FORTH), and he loves the ability to just poke around in memory however he likes. Being so close to the hardware helped him learn important lessons about how memory actually appears to a program, and what pointers really are. I'm afraid I've ruined him for compiled languages though. He seems distressed that you can't extend the C compiler easily. :)
I've never attempted a really large project in FORTH though, mostly limiting myself to (and this is a whole level of nerdity in itself) RPG tools for Traveller and some very basic robotics stuff using a Pololu USB servo driver.