Wednesday, July 2, 2008

Am I missing something about Forth?

As part of my "educate myself about FPGAs" curriculum, I've noticed Forth turning up in a lot of Google hits. Forth has always been on my long-standing list of languages I wanted to learn. I remember spending my last bit of hard-earned cash in the early 70s to buy an HP-35 programmable calculator. It got me through my final Electrical Circuit Theory exam so was worth the hundreds of dollars it cost me. It had just arrived here in Oz and the examiners didn't have time to change the rules about pocket-size programmable calculators (they didn't exist before the HP-35).

The HP-35 was a Reverse-Polish stack machine. I loved it. Stack machines seemed so obvious I couldn't understand why they never took off.

So when Forth came out I was intrigued to try it but never found a way to do so. There was no Internet then so one couldn't just download a copy and try it out. I saw Forth mentioned in lots of places by people I respected. There was even a microcontroller project (Elektor again?) with Forth being the built-in interpreter rather than BASIC.

So I downloaded gForth and worked my way through the included tutorial. OK, I can print "Hello world" and add some numbers. I also started reading Thinking Forth.

But what makes Forth so interesting to so many obviously intelligent people? Found a 1-hour movie where a skilled Forth developer writes some code. It left me quite cold. It seemed to take ages to write the simplest things. And in the end it looked so much like a recursive decent parser I kept asking myself why didn't he just use one to begin with. OK so that wasn't the point. He was showing people how he thinks in Forth and he succeeds really well in that and deserves praise for that.

But I couldn't see any advantage in using Forth for that particular task and it actually seemed really slow and tedious to use Forth compared to, say, Perl and RecDescent. Part of my task as a Perl programmer when I am about to write new code is to check CPAN for modules which already do what I need. "The best programmers don't" as they say. So there's no doubt a different mind-set between Forth programmers who appear to want to write everything themselves "because it's so easy" and say, Perl programmers, who tend to just re-use existing code from CPAN and rarely write code themselves at all.

Something to ponder a bit further.

Doing what I like

I occasionally browse through Elektor magazine. I've always been interested in gadgets especially the electronic ones and although I haven't earned a dollar building circuitry for a long time now, I've tried to keep up with what's been happening in electronic design. In the late 70s I wrote a BASIC program to convert circuit diagrams into wirewrap instructions and although I sold a copy to a small electronics firm I never pursued it as a marketable product (fool me!). I was never willing to spend the ten of thousands of dollars needed to buy an auto wirewrap machine and my vision of what I wanted to do never got to the "make a living" stage. So most of the time I was content to manually type in the circuit diagram to my program and let it calculate the length and order of the wires and then I could manually wrap my little circuits and get on with the fun of testing and debugging them.

I've referred in another post to Louis Savain's Universal Behaviour Machine. He's been getting heaps of flak in his comments posts, not the least because he doesn't seem willing/able to move beyond rhetoric about why a UBM (parallel processing) is a better paradigm for computing than a Universal Turing Machine (serial processing). One of the comments caught my attention. It suggested that Savain's UBM is "nothing more" (I love that phrase, it immediately alerts me that there is something to look at) than VHDL. "What's VDHL?" says I. Quick Google throws up a wealth of info and links including a series of articles in Elektor on FPGAs which I had glossed over. FPGAs were always attractive but the devel kits were typically thousands of dollars and not for doodlers like me. But then I saw an ad for a really cheap evaluation kit. For $39 I don't care if I blow it up, it's worth trying out.

So the web of ideas goes something like: no UBM yet -> make one -> how? -> modify an existing micro-core -> how? -> learn how to build/install/modify a micro-core in an FPGA -> how? -> buy a cheap eval kit -> where? -> aha! Avnet just released one -> order it -> learn about VHDL -> how? -> read on-line stuff -> note that some people are using Forth to program FPGAs -> how? -> learn Forth -> install a Forth micro-core on FPGA and try it out... and so on and so on.

But the best news for me is that I can use all those years of building logic systems once again. I already know about sync pulses and NOR/NAND logic and multiplexed buses etc. etc. It's quietly gotten a whole lot easier and cheaper to implement this stuff. My last attempt was an ASIC in the 80s, really expensive to design, test and make.

And it's something I like doing.

A replacement for Make

Bzr and Hg interesting but client wants Perforce so am moving client's repository from Clearcase to Perforce. Code base (mostly) written in C++ to run on various platforms including **nx and Win.

I'm taking this opportunity to see if build system could be improved.

First requirement is to replace Clearmake. Looked very closely at SCons and was about to make (pun!) it the build tool for new repository when I discovered an article about Makepp (awful name, sounds like a pre-schooler discussing urination), i.e. Make++ => MakePlusPlus => Makepp. My one major misgiving about SCons is that it is written in Python and although I like Python I don't have the years of experience in Python that I have in Perl. Makepp is written in Perl!. SCons even uses (a limited selection of) Python commands as its scripting language. Makepp OTOH uses GNU Make syntax for most of its scripting language but with the ability to insert Perl code when needed. Not sure if Make syntax is of much benefit to me. I haven't used anything but the simplest Make scripts for years. That's what MakeMaker.pm is for! But, like SCons, Makepp has some pretty intelligent default behaviour. It works out what language the source is in, looks for any required include files, knows the useful options for a host of compilers etc. etc. And, doesn't suffer from Make's recursion problem.

Makepp, again like SCons, has another very useful feature: the ability to correctly track intermediate files. One of the urgent problems, to me at least, with our existing build system is that it does a "clean" build every time. Nothing is kept from previous builds. I suspect this was not intended initially but is a consequence of how Clearmake/Make are being used. No wonder faulty branches are being checked in. I wouldn't wait 5 hours to confirm a build either if I were a developer. I'd much rather leave it to the overnight run and clean up the mess in the morning. So, hopefully, with quicker builds there will be less faulty code checked in.

Anyway, from my initial investigations, it looks like Makepp is the way to go.