Re: Speaking of Forth..

Nuts and Volts July issue has a good article on progrmming in FORTH. If you want to learn FORTH, try getting a hold of PYGMY FORTH from the internet. That's a pretty easy one to work with.

New Micros used to have a pretty inexpensive micro based on the HC11 that runs on MAX-FORTH. Their ISOPOD also runs on FORTH.

I like FORTH. The programs I write in FORTH run faster than the ones I write in BASIC. I can write device drivers without having to resort to machine language (which often isn't available in BASIC anyway). You can test software easier. BASIC is pretty easy to learn, but FORTH isn't that much more difficult and certainly no more incomprehensible than C. Over all I find it ideal for robotics. Some people disagree, but to each thier own.

I agree. Fourth sounds like a wonderful concept at the beginning but once you get into constucts for prrogramme flow is becomes a mess and breaks all it's own rules.

Yup,

I am a goofball. But I have an Emmy sitting on my mantle, and I couldn't have done it without FORTH. Just my 2E-2

---------------------- ftp://ftp.armory.com/pub/user/rstevew/FORTH/pygmy14.zip ftp://ftp.armory.com/pub/user/rstevew/FORTH/pygmy15.zip

To answer your question as directly as I can, I don't know of anyone who sells a kit of parts, to do Forth. Generally, you either get a single board computer with Forth on it,or get a Forth into a PROM and install it on a single board computer, if you want some hands on, D-I-Y.

For instance: New Micros sells a board based on the 8051, which comes with support for BASIC, Small C, FORTH and Monitor for $39. The manual has quite a few examples written in each language. Although the board is large (about 6"x4") and the processor somewhat dated, but one of the more popular cores in existance. You still get more computing power and flexibility than you do with a Stamp, which costs much more.

As Chris mentioned we also sell a series of boards based on the HC11 with our Max-FORTH in ROM.

Our latest offerings, the IsoPod(TM) and ServoPod(TM) have our new language, IsoMax(TM) which has a statemachine real time operating system on top of a Forth procedural base. These represent 20 to 40 times the processing power and several times more interface features for comparable prices. These can also be programmed in C. We considered Basic for these later boards, but are dragging our feet, not well motivated to do so.

Let me ask you, do you ride a bicycle? Did you start on a tricycle? Was it akward going from the trike to the bike? (If you didn't ask someone who did.) The first time on a bike you came to a corner and pulled the handle the way you wanted to go like you would on a trike, and fell over... you experienced how riding a pedal vehicle which didn't require balance difference from one that did.

The actual physics of how to turn a bicycle are pretty fascinating. Most people just do it and don't think what they do. You must use negative steering. Too go left, you first push right. (Amazing but true!) Pushing right leans you to the left. Once leaned you return the bars to neutral. The curved path that takes you around the corner. But its all so easy, once you've learned it, it's natural, like, "riding a bike."

Riding a trike does teach you some things you use with a bike. You learn to pedal. You learn leg coordination. You learn some basic balance, enough to stay on the vehicle for instance. But you actually learn exactly the wrong way to go around corners if you ever want to move on to a bike or a motorcycle.

And strangely, for the rest of your life, if someone asks you what to do if want to go left, you THINK you just turn left, even though you actually DO something almost opposite and much more complicated from that. Would you say the tricycle screwed up your thought process for riding the bike? The answer must surely be, in some fundamental sense, Yes. Doesn't mean you can't learn to ride a bike, and it doesn't mean you can't learn to go around corners, but you'll probably always be confused, thinking-wise, about how you go around corners.

So, you are saying this is not a language you've ever used, personally...

but you did know some people (you didn't like) who did it badly?

Definitely, an image there! I like it.

Another cut on this....

Having wide experience with various languages, particularly when they stretch your thinking processes productively, only helps. It never causes you to be more confused. It just gives you more tools in which to think.

Lisp, APL, Forth, C, Clu, C++, Bliss, ADA, assembly language, VDHL and Verilog, etc.... these and many others can only broaden out one's experience. Some will expose you to task and process semantics, or to iterators, or to various levels of thinking, from the ideas of combinatorial logic to sequential logic with state, the various aspects of latches and registers, ALUs, to inheritance, garbage collection, and deadlocks.

More is better and no matter what you start out with, there will be something else out there made just a little harder to grasp, because of the reinforced, preconceived notions you haven't yet gotten rid of. But that's just the price you pay to learn. Not some problem of a good language.

And the greater the breadth and depth of one's mental tools, the more facilely one can address the myriad problems one meets in programming life. More is better, up to a point. Then its making some decisions and staying leading-edge proficient in a few.

The question about using forth daily, for me, is more a matter of who would pay me for those skills if I should take the effort to become well-versed in them. No one has ever even asked me if I knew forth, in my 27 years of active, full-time professional programming. I've *loved* reading articles about forth and I did play with it some. But work in it seems far between, for most. I suppose the business is large enough for those living in the cracks, so to speak. But it's a small pond, as they say.

For my own hobby use? Entirely a different question. I intend to get some more time into forth. Just because I liked playing with it before and, I'm sure, will enjoy it again as I get some time to dig deeper.

So a lot depends on one's goals. If one is trying to develop marketable skills to the broader marketplace, then probably forth should be set aside for a while. If one is trying to be a big fish in a small pond, then forth may be an opportunity to achieve that. It's hard to know what to advise.

Jon

From my experience:

I have programmed in BASIC, FORTRAN, Modula, Assembly, machine code, C, C++, LISP, FORTH. and LabView. FORTH and LabView make me wish everything else worked as easily. LabView tainted me forever. FORTH broadened my horizons, and taught me how to better break down a task.

Mike

So what do you use now?

-- Randy M. Dumse

Caution: Objects in mirror are more confused than they appear.

More interesting than what you use now, and more pertinent to this thread, might be, what did you use first? Was it BASIC?

Your claim you must be fully insane to make RPN work, is overstated, but it certainly indicates your strong personal bias against RPN. An interesting observation through the years, was certain groups seemed to find Forth more natural than others. For instance, Germans and Chinesse took to it quite easily. Many speculated it was because there spoken language was much less mid-fixed than English.

RPN, for those who don't know, stands for Reverse Polish Notation. It's sort of like saying the nouns first before the verb, so a sentence in English would be "You and I" would be presented "You I and" or in math "2 + 3" as "2 3 +".

Many people who used HP calculators liked Forth, because they had already made their peace with RPN.

Which order language is structured in is just a cultural or "mind set" bias. So someone speaking in an odd notation can sound "insane" to someone only comfortable in the notation he first learned. (i.e. Throw the horse over the fence some hay.)

RPN does work. It has to. It is how the machine itself works. Every compiler has to translate whatever notation into RPN at the machine code level. The issue cannot be if it works or not, because that's how the machine works, but if you feel comfortable working in it. And clearly you've indicated you don't.

I'm not wild about RPN myself, but I've made my peace with it. Ever since I learned its how the machine works, and even if I write in mid fixed C (or BASIC) with left hand and right hand values, the end result will be machine code that identifies two parameters first, then performs an operation on them (quintessentially post fix). I often chuckle at the comment "Forth is the only language I know, that uses a human for a preprocessor" but it is pretty much the truth. Well, I'm okay with it, because I have developed my mind to work with this different notation, and appreciate how Forth is small and powerful, and being closer to "how the machine thinks" is okay with me.

I believe that goes to the OP's concerns, that what he learns first would set his bias for further work. Like my example of trike and bike, if you are biased for mid fix notation, you may have trouble thinking differently when using a post fix notation

-- Randy M. Dumse

Caution: Objects in mirror are more confused than they appear.

I ended up using Visual Basic mostly the last many years. It is quite the mess also but can be easy to do fairly dramatic things.

My favourite is still assembler for full control and speed. Once your libraries are written, control type things are just so easy and natural.

In the end all languages end up with a SOAP. (Stack oriented Arithemetic Processor) This is the only way I know to process any mathematical puzzle and lives the RPN style. I just don't feel us, as higher level beings, should have to logic twiddle to solve easy mathematical puzzles. It's not the way we think (maybe habit?)

Forth kind of fell apart when people wanted to do real world things like strings of text and floating point numbers. When the verb precedes the noun the complier knows what to expect on the programme line but when you throw a string of characters or a floating point number or a boolean statement you make a lot of guesses until the verb is in.

As a control language expecting only integer math inputs Forth is probably one of the most powerful (depending how you define it) languages/complilers going. I believe there was a Forth complier with about a 100 byte kernel once and it could become big and fancy but took a lot to get it there. When I weas playing with less than 1K of memory this was important then.

Yes, yes. I very much agree. You make two really good points here. To your later, yes you have written the second example in PN or polish notation, where the verb comes first and the nouns come second. But notice how you have to use precidence markers to make it work out. (You used almost the universal precedence markers the "parens".)

The reason that Forth uses RPN, is no precedence markers are necessary. So Forth is deliberately written in the order the machine needs the parameters feed to it.

In your first point you hit the nail, smack dab on the head. We mostly think of math as written on a two dimensional plane. Specifically, the chalk board we learned to do our fist math on. So when we say 2+3 = 5, we are really thinking of our first exposure to math.

2 +3

Looks like good fun.

That kit your using looks a bit like the older metal mecchano sets.

A compiled basic is basic that is converted by the compiler from basic to machine code on your pc so the microprocessor can run it directly. Usually runs a good bit faster than interpretted basic.

A lot of basic's are interepted, that is a program runs on the micro that interprets your basic code as it runs. Usually a lot slower.

Alex

Twenty years ago I built several robots controlled using up to eleven FORTH processors running in parallel (Rockwell R65F11 - 6502 based). That took care of real time control. Higher level logic was implemented in APL. That, in my opinion, was a beautiful combination for robotics: I could do low-level stuff with incredible ease (FORTH) and attack matrix transforms in a very natural way (APL).

To the O.P.: Learn as many languages as you can. Don't get stuck with the "linear" thinking of today's popular languages. Much like assembler and FORTH have limits, today's popular languages will be considered incredibly clunky in the future. APL, in my opinion, is the closest you can get to programming at the speed of thought. The failure point of today's programming methodologies is that the programmer still has to deviate from the problem to be solved to focus on the mechanics of the process.

You know, I really don't get this FORTH will make you think differently stuff. I've written programs in FORTRAN, PL/1, COBOL (when it was done on cards), BASIC, C, PASCAL, FORTH, about 7 or 8 different CPU assembly languages and I really don't see all THAT much difference.

Basically a computer moves data from here to there. Higher level languages cover up many of the details, which is a good thing when you have a big project. The lower level languages leave more of the details up to the programmer, which is good if you're working with a microcontroller.

Most of the differences I see are stylistic. In PASCAL it's PROC/ENDPROC, in C it's {}. You develope your program the same way, though, declare your variables, write your subroutines, write a main program that calls those routines. It's all about where your data goes and how it gets there.

Different languages handle details differently making them better suited for particular jobs. COBOL handles large records better than FORTRAN did, so buisnesses used it for book keeping. FORTRAN handled math better than COBOL, so that's the language scientist used.

I wrote a FORTH kernal for the PSoC (see previous posts) because I wanted a language I could write on my Palm Pilot. I could have written on in BASIC, I guess, but useful BASIC interpreter is big if it's fast or slow if it's small. FORTH is pretty small for what it does and very fast. It is also pretty uncomplicated to write.

When I write a program in FORTH, however, I do the same thing I would do if I wrote it in C. I decide what the data is and where it will be located. I write subroutines that handle the different tasks I need to be done. Then I write a main program that ties it all together.

I will say that FORTH makes it easier to follow good programming practice. You tend to write your code in small peices that are easy to test and easy to follow. My earlier BASIC programs tended to be spagetti code that took a long time to debug and were impossible to follow if I looked at them after a break. But, I also see the same tendency in writing in C or PASCAL.

chris in napa

I completely agree. Language is just a means to convey an idea or concept. This holds true for programming languages as well. The nice thing about FORTH, is that it is a language creation language. You build what you need. Where other languages are written to do exactly what you need, and even named after their target audience, ( BASIC, COBOL, LISP, FORTRAN ), FORTH lets you build what you need.

The reason why LabView spoiled me for other languages, is that it's organization is graphical in nature, and has caused my text based programming to atrophy.

As a side note, you had ought to look at IsoMax on the IsoPod. If has it's roots in FORTH, but is moving towards being a language more specific to the hardware capabilities of the IsoPod, thus enabling users to move past the nitty gritty of talking to the hardware. It also has introduced state machine flow control, and multi-tasking.

Mike

Amazing. Small world. That chip was wonderful. I did a ton of work with this chip.

The parallel processor I mentioned had 11 of them. There was a master that communicated with a PC, a control panel interface that communicated a ran a control panel with buttons, knobs and a 3-axis joystick. I even designed a floppy-disk controller card and wrote all the appropriate drivers to use as block storage for FORTH. The rest of the processors were servo controllers (one per axis) controlling DC servo motors. PWM was done on a separate card that simply took a parallel PWM setting from each of the processors and produced the signal by using comparators. Each motor was controlled by a full-bridge setup using 2N3055's. I also had display (LED alphanumeric) general-purpose I/O cards designed into the system. Without counting the motor drive amplifiers, the whole thing occupied six rack units in a standard 19in rack.

I built two robots that used this system. One was a relatively conventional

6DOF robot arm. The other was a four-legged walking spider (slow) that used an oil-damped pendulum to stay horizontal (I patterned it after work I had seen out of a Japanese university back then, forget which one). Anyhow, it all worked very well. I'm going back to 1983~85 here, so I don't remember all the details. The PC implemented a programming console that could be used along with the control panel to program movement sequences. All of the console work was done in APL barring some real time stuff that had to be done in assembler.

I sent you a couple of pictures of the hardware privately. Regrettably I don't have any pictures of the robots, but, for some strange reason, I kept the parallel processor and the motor drive amplifiers in my garage all this time!!!.

controllers

conventional

I hear a chant for FORTH coming on!!!!!!!

FORTH! FORTH! FORTH! FORTH!

I have been using Randy's FORTH based microcontrollers in motion picture and television equipment for a decade now. What amazes me, ( and my supervisors and co-workers), is how quickly you can get stuff up and running as real product.

My Squishy Lens was based on a 68hc11, and a handfull of NMI's boards. I could not have done it so quickly without FORTH. The optical and mechanical design took 6 months, the electrical took a week, and the software was less than a month. This would have easily been a 1 year development cycle for my employer, had I not used FORTH and Randy's boards. This resulted in about $200,000.00 more for my employer in revenue the next year.

I wish there were an embedded systems award, so Randy could get a trophy.