A quick list of commerical projects I have written in Forth including Tachyon
Peter Jakacki
Posts: 10,193
Ever wondered where Forth gets used? Does it get used at all? You may be very surprised but rather than try and list all the other ones I might know about while missing out the other 99% I thought I would just try to list and describe a little bit of the stuff that I've done myself over the years.
Point of Sale terminals
This was in the 80's and my first Forth project and ran on Rockwell R6511AQ 8-bit CPU. Also did other POS terminals into the 90's as well with 16-bit chips like the M37702 based on the 65816. All these units were WOW stuff at the time and I could modem across the country to individual multidropped terminals and see what was happening while it was being used. Of course I could view and update anything as well as the software remotely. Working out of a company's offices one time in Dallas I was asked if I could interface these EFTPOS terminals to my stuff but when they came back a few hours later I already had it up and running because I could interact with the terminal while I felt out and developed the interface despite the lack of documentation. I even figured out what a special IC did on one piece of equipment because I could just fire all these various sequences and tests at it as fast as I could type. The engineers were speechless, how? impossible? What! How?
Some other companies and teams would try to do better with conventional and "proper" languages but would end up needing more and more memory and CPU power and time (and people). Is that better? Go figure.
Vending machines
There have been all kinds of vending machines that I have made over the years but mostly card type vending for when phone cards were the rage or even ones used for gambling (mostly US) etc. The CPUs used were anything from 6502'ish chips to MSP430s. One time the client who I supplied the boards to had a problem with my "software" since it allowed five dollar notes to be gobbled by the machine. Using the Forth on-board I could talk to machine in operation but also on the bench and found the design of the note acceptor wanting but I only receive greater threats from the client and the note acceptor manufacturer. Some further software testing and now with data logging built in using the Flash program memory and being to talk to machines via the front panel IR link allowed me to produce detailed reports that showed that there was no fault in the software. Instead it turned out that the note acceptor continually rejected certain batches of five dollar notes then ended up curling them around its rollers while trying to reject it and not knowing that it had failed. I kept my customer.
Mobile phone "booth"
Back in the 90's I did versions of mobile phone boxes that included VGA resolution color LCD panels and even SCSI drives that held advertising slides. These units were mounted on buses and trains mostly.
Coin operated Taxi booking
Back in the 90's I invented these small boxes mounted like parking meters or on walls of clubs and shops etc that allowed you to insert a coin to book a cab. The machine would print out a receipt with the booking number etc and the cabbie would pull-up asking for that number. Forth also allowed me to interface to the cab companies computer interactively to figure out the protocol and timing etc so that in one afternoon I had taken a control pcb which sat in a shoe box (literally) and had it up and running handling multiple dtmf phone lines and booking cabs.
Multi-channel protocol converters
There are all kinds of datacommunications protocols that I've handled and Forth also made it very easy to debug in a powerful and flexible way while testing and developing the software since the equipment you interface to does not always behave well. Chips have been mostly 16-bit like the M37702, MSP430, or ARM chips as well as the Prop of course. These kinds of units are buried in roadside cabinets, in air traffic control rooms, plant control rooms, etc.
Test instruments and metering
There have been a number of specialty test instruments that have been created and sometimes I create them even for myself as in the case of needing to interface to GPIB on a HP MSO. Forth allowed me to automate and discover ways to get the most out of them.
Industrial Control
I don't know where to start here as there have been so many applications but be assured that when you are testing and developing on-site that in many cases Forth has proven to be very useful in getting things worked out and tuned, and also in being able to get out of the place. Nothing like showing a customer a possible machine sequence with a quick one-liner, I just love em.
Fume cupboards
Talk about encoders and sensors and VFDs, these fume cupboards have stacks of inputs and outputs to take care of. It was always nice to be able to sit beside one I designed and plug in a PC and test out the various sensors and outputs in operation. One time my PC went crazy and it turned out that the sparky had wired a nasty VFD a few meters away from the motor with cables running alongside signal cables, and no shielding. The PC keyboard just picked it all up and spat it out.
Data logging
There is a big market for high-end data logging for security companies and government. I've used ARM chips as well as Props and both times it was rewarding to be able interact with the data and improve methods and see the results in real-time.
It's after 2AM here and I'm getting tired especially since I realize now that I have barely scraped the surface, but Forth is out there and running year after year all over the place and doing what it needs to do without requiring an overkill in hardware resources to support it. If I find the time I will add some more cool stuff and details to this thread.
Point of Sale terminals
This was in the 80's and my first Forth project and ran on Rockwell R6511AQ 8-bit CPU. Also did other POS terminals into the 90's as well with 16-bit chips like the M37702 based on the 65816. All these units were WOW stuff at the time and I could modem across the country to individual multidropped terminals and see what was happening while it was being used. Of course I could view and update anything as well as the software remotely. Working out of a company's offices one time in Dallas I was asked if I could interface these EFTPOS terminals to my stuff but when they came back a few hours later I already had it up and running because I could interact with the terminal while I felt out and developed the interface despite the lack of documentation. I even figured out what a special IC did on one piece of equipment because I could just fire all these various sequences and tests at it as fast as I could type. The engineers were speechless, how? impossible? What! How?
Some other companies and teams would try to do better with conventional and "proper" languages but would end up needing more and more memory and CPU power and time (and people). Is that better? Go figure.
Vending machines
There have been all kinds of vending machines that I have made over the years but mostly card type vending for when phone cards were the rage or even ones used for gambling (mostly US) etc. The CPUs used were anything from 6502'ish chips to MSP430s. One time the client who I supplied the boards to had a problem with my "software" since it allowed five dollar notes to be gobbled by the machine. Using the Forth on-board I could talk to machine in operation but also on the bench and found the design of the note acceptor wanting but I only receive greater threats from the client and the note acceptor manufacturer. Some further software testing and now with data logging built in using the Flash program memory and being to talk to machines via the front panel IR link allowed me to produce detailed reports that showed that there was no fault in the software. Instead it turned out that the note acceptor continually rejected certain batches of five dollar notes then ended up curling them around its rollers while trying to reject it and not knowing that it had failed. I kept my customer.
Mobile phone "booth"
Back in the 90's I did versions of mobile phone boxes that included VGA resolution color LCD panels and even SCSI drives that held advertising slides. These units were mounted on buses and trains mostly.
Coin operated Taxi booking
Back in the 90's I invented these small boxes mounted like parking meters or on walls of clubs and shops etc that allowed you to insert a coin to book a cab. The machine would print out a receipt with the booking number etc and the cabbie would pull-up asking for that number. Forth also allowed me to interface to the cab companies computer interactively to figure out the protocol and timing etc so that in one afternoon I had taken a control pcb which sat in a shoe box (literally) and had it up and running handling multiple dtmf phone lines and booking cabs.
Multi-channel protocol converters
There are all kinds of datacommunications protocols that I've handled and Forth also made it very easy to debug in a powerful and flexible way while testing and developing the software since the equipment you interface to does not always behave well. Chips have been mostly 16-bit like the M37702, MSP430, or ARM chips as well as the Prop of course. These kinds of units are buried in roadside cabinets, in air traffic control rooms, plant control rooms, etc.
Test instruments and metering
There have been a number of specialty test instruments that have been created and sometimes I create them even for myself as in the case of needing to interface to GPIB on a HP MSO. Forth allowed me to automate and discover ways to get the most out of them.
Industrial Control
I don't know where to start here as there have been so many applications but be assured that when you are testing and developing on-site that in many cases Forth has proven to be very useful in getting things worked out and tuned, and also in being able to get out of the place. Nothing like showing a customer a possible machine sequence with a quick one-liner, I just love em.
Fume cupboards
Talk about encoders and sensors and VFDs, these fume cupboards have stacks of inputs and outputs to take care of. It was always nice to be able to sit beside one I designed and plug in a PC and test out the various sensors and outputs in operation. One time my PC went crazy and it turned out that the sparky had wired a nasty VFD a few meters away from the motor with cables running alongside signal cables, and no shielding. The PC keyboard just picked it all up and spat it out.
Data logging
There is a big market for high-end data logging for security companies and government. I've used ARM chips as well as Props and both times it was rewarding to be able interact with the data and improve methods and see the results in real-time.
It's after 2AM here and I'm getting tired especially since I realize now that I have barely scraped the surface, but Forth is out there and running year after year all over the place and doing what it needs to do without requiring an overkill in hardware resources to support it. If I find the time I will add some more cool stuff and details to this thread.
Comments
After that I did write my own Forth for 6502s initially and then 65816 and the more powerful M37702 16-bit microcontroller. I even sold credit card sized Forth controller modules although my main use was in my own commercial projects. I also wrote a Forth for the MSP430 and for the LPC2138 when ARM chips were starting to become more available. In fact I entered that into a Philips/CircuitCellar competition as the "noPC" as a very late entry, without using any sponsor's boards or software tools, just all my own custom stuff. Despite that "disadvantage" I still ended up 2nd place and Philips (now NXP) upgraded the slow I/O on all the chips after that when they could see that I just managed to bit-bang color VGA with it on top of all the other things it was doing (who woulda thunk it).
When I came across the Prop it was the ease of using VGA that first attracted me but the chip and tools looked horrible for implementing a Forth plus I was actually enjoying Spin and as another compiled language it was actually very simple too and got the job done without a mess of header and make files. The first Forth (by Google's Cliff Biffle) I saw on the Prop was encouraging but unusable too although I did try to use it but gave up after which PropForth seemed quite usable so I started using that later on as I didn't want to write another Forth. But for a whole heap of reasons including the dismal speed I became disappointed once again and decided to use Brad C's BST that was available to write my own Forth, except I knew it couldn't be conventional because the Prop itself wasn't. BST let me see and tune the build whereas the Spin tool was way too limited, I just wanted one easy to manage source code to be built and downloaded at the press of an F11. So Tachyon was born based on a fast and compact bytecode model designed for the Prop and built using BST, nice and simple, and it was fast and more importantly I could use it for real commercial product rather than just playing with benchmarks, samples, and ANSI standard code.
I can see you have mastered Tachyon/Forth. I just cannot get my head around the reverse notation - probably just old age now as I am certain I could have mastered it years ago.
Tachyon is absolutely brilliant Peter! Congratulations for making it available for the Prop, and the support you give to everyone here.
Thanks Ray, and we still have to catch up too, maybe Melbourne. The trick about reverse anything is simply to adjust your thinking and move in the same direction. You saw the quick one-liner I did for a 20kHz pulse? How about I write a conventional syntax version as a one-liner and compare that against my code:
Which is more natural do you think? Yet it is because we are taught to think unnaturally that we end up thinking natural is strange. Why doesn't this banana taste not like my rollups? Either way we have a brain that is flexible and with it we can speak multiple languages, strange at first though they be, so why not multiple computer languages, strange at first though they be?
I don't know about "taught to think unnaturally". What is "natural" ? Anyone who has been taught maths for any length of time is used to infix notation x = 2 + 2 and the bracketed form for functions y = f(x). Similar forms are used for sums, integrals, differentials etc. This same mathematical notation is used the world over and may be a reason for people's minds stalling when it comes to Forth.
Of course you could say that maths notation is "unnatural" I guess.
Oddly enough Forth is inspired by the work of the mathematician Łukasiewicz, whose "Polish Notation" did not catch on with other mathematicians.
I must admit that your one liners always look short and sweet. I like to think those extra 8 characters of the post fix version are not much extra typing and offer valuable clues as to what is going on. They tell me that BLINK, KHZ, delay and MUTE are functions and what parameters they take. A sprinkling of actual syntax is helpful when things get complicated.
I suppose it all starts to become a philosophical debate after a while but the main point is that while it is convenient to have walls that we don't at the same time need to constrict our thinking within them. As to what is "natural" that has a lot to do with culture so what is natural to one person may be completely unnatural to another. Yet we are not preprogrammed bots, I think we can do better. As to maths and notation it is very unnatural really although convenient like our walls. For example if I have 6 bananas and eat 2 I then have 4 bananas left which is the sequence it all happened in too. In maths notation I have 4 bananas left because I had 6 originally but ate two, convenient, but not the way it naturally happened.
"if I have 6 bananas and eat 2 I then have 4 bananas left" is like "6 - 2 = 4". Which is, as you say the sequence it all happened in. Nothing wrong with math notation there.
Of course in maths you can eat you bananas before you get them "-2 + 6 = 4"
Or you can predict the future as you say "4 = 6 - 2".
Of course such maths does not have any notion about time. It just states relationships that just "are". Which leads to the interesting result that physical laws, like Newtonian Mechanics work the same if time is run forward or backward.
Note that in maths the equals sign is not an operator. Its an assertion that the value of the left hand side is equal to the value of the right hand side. Whichever way around. This is one point that programming languages often get wrong, like C.
On the other hand my experience with Forth, or should I say the lack of it, has been very practical. I was fascinated by Forth back in 1983. Even had the book Starting FORTH by Leo Brodie, still got it some place I think. Didn't like the style but anyway that line of enquiry came to an end because I was working on a multi-processor, multi-tasking control system that had to keep up with a machine stamping out 10000 pieces of it's product every minute. I could not imagine how a Forth interpreter would keep up with that.
And so it went with many subsequent real-time embedded projects over the years.
At the other end of the spectrum, I could not imagine the CAD system I worked on for a long time being written in Forth. It would be unintelligible, might as well try to do it in assembler.
Hehe, Forth is assembler, albeit a powerful macroassembler but DUP SWAP DROP are just Forth VM opcodes if you like. However your reference to an "interpreter" not being able to keep up is not quite correct in the sense that we think of an interpreter like Spin or Basic tokens etc, they are slow. The standard Forth runtime interpreter only reads addresses and calls them, so it's a tiny bit of overhead but not much really. The slow down can come from manipulating the stack unduly as would be the case in trying to implement an FFT in pure unoptimized Forth, in that I would agree. However it's been my experience that the very application you mentioned would be a pushover for Forth, been there, done that.
BTW, Tachyon bytecodes are addresses too, they are an 8-bit entry address to PASM in the first 256 longs of the Tachyon VM cog, that's why it's so fast as there is no need to decode the bytecode.
Thinks....perhaps if they had used Forth from the get go they would have realized one processor was not going to be enough much earlier and saved a lot of effort and expense...What was a real drag was that it took most of the day to recompile the entire system on two Intel development systems with those big old 8 inch floppy drives.
Those drives are big clunkers and I say clunkers because they used those head load solenoids to clunk them onto the floppy when it was ready to read. Clunk, seek, clunk, seek, clunk! Not only the drives but the MDS 80s itself was a non luggable beasts. Never owned one, way way too expensive for a time when new CPUs were popping up faster than mushrooms, wouldn't want to miss out on all the fun with them now, would I?
You might be right about the performance but something at the back of my head says maybe not because I recall similar projects and the main problem was that the compiled software theoretically could run at native speed, but it ran at native speed through a jungle of library methods. Being library methods they were designed to be all-purpose but there ain't no such animal however as a consequence they suffered bloat and inefficiency making everything more complicated and slower. Perhaps I'm wrong, but that's what I've seen.
I know what you mean about compilers and libraries. However in that particular system the high speed real-time parts were written in assembler, much of the rest in PL/M. There was nothing in there that was not written in-house and tailored for the job. After all there is pretty much nothing in the way of library support in PL/M anyway, unless you were programming for the ISSIS II operating system on the MDS itself.
Holy moly!!!!!!!
That's about 6ms per piece. It gets worse. Every piece had to have it's density measured at 8 places along it's length, other defects checked, out of spec parts ejected as needed, so we are down to less than a millisecond iteration rate. Average weight, standard deviation etc calculated on the fly, safety systems checked, data communicated out of there, etc etc etc. Pretty tough when your 8 bit processors are only managing about 1MIPS.
Hence the multiprocessors. I guess though it was stamping more than one at a time though.
You did well indeed.
Can anyone guess what this machine was making?
Edit: Oops that wouldn't be "stamping" though.
Wow! No wonder Tachyon Forth is so capable. You had plenty of experience to draw on when you wrote it. I'm still scratching my head trying to think of a way to make a more traditional interactive language even a fraction is powerful as Tacyhon is on the Propeller.
Ah yeah. When I said "stamping" I did not mean it literally. It was more like "extruding". But not extruding either
Let's hope P2 comms gets resolved soon. That on will be both a FORTH beast and playground.
When I said "stamping" I did not mean it literally. It was more like "extruding". But not extruding either - Makes no sense.
mirror image pairs sort of exclude food processors for something like potato chips or sliced dried fish (they eat stuff like that in @Heaters area), no need to have two mirrored image pairs.
10000 a minute basically also states that the things can not really be big or you have problems to get them away quickly. But measuring 8 times the density says the things can not be very small.
Toothpicks? Matches? Wires?
While you are torturing us I torture you back: "How you can speak a full minute in coherent and correct English language without using the letter a"?
Enjoy!
Mike
Thanks for taking the time to write about your very interesting experiences with Forth. I can only imagine that this thread will lead to more people looking at Forth as a Propeller programming language.
I must admit that I am now more interested.
Chocolate bunnies for Easter? .... that was so last month ago. :-)