Starting FORTH -- Running GForth and Tachyon Side-by-Side
JonnyMac
Posts: 8,918
Okay, I'm going spend my lunches for the next month or so wrapping my head around Forth. Despite its age, Starting Forth seems to get the most recommendations. Was motoring right along until the book used this definition...
Well, darn, I make the post, play for another minute, and then sort it out:
: STARS 0 DO STAR LOOP ;I see a note in the Tachyon about FOR NEXT but am having trouble locating syntax rules.
Well, darn, I make the post, play for another minute, and then sort it out:
: STARS FOR STAR NEXT;
Comments
Try typing into Tachyon without creating a definition The other thing is that you can still treat a FOR NEXT the same way as DO LOOP in that you can reference the index I, LEAVE when you want, step the index BY an amount, and change the starting index FROM the default of 0 etc. The equivalent in GForth would have to be within a definition so it would look like this: I'm bringing up the Introduction to Tachyon page and I will go through that to make sure it is up to date but any feedback you can give me on what I might have overlooked will be appreciated.
If you do use pfth, I would suggest using the version that runs under spinix. That provides an OS and tools for editing Forth source files. Or you can use one of the stand-alone versions of pfth if you don't want to mess with spinix.
Why don't you hook up your favorite peripherals and start playing with them or even a VGA monitor and load VGA.fth where you can even redirect all console output to the screen etc.
EDIT: I reduced the size of the VGA module down to under 700 bytes so I have incorporated it into EXTEND as standard along with the LCD and KEYPAD modules etc.
I know I'm making you nuts with this -- and it's not my intention --but I want to learn Forth properly. And, frankly, there's lots of great documentation for standard Forth. Tachyon assumes one already knows Forth. This is not a knock -- it's just what I'm facing. I'm torturing myself with this side-by-side thing a bit so that when I come across something interesting in Forth, I can figure out how to port it to the Propeller.
I'm not a fan of VGA output. I would rather just work through a terminal. I am running Tachyon on an EFX-TEK HC-8+ which has a couple '165 shift registers and a full-duplex RS-485 port, along with basic IO points. It's the platform I deploy in my "Hollywood" projects using Spin. A big part of this exercise is to figure out if Tachyon would make me more productive as I'm often given very little time to program those big projects.
If you want to try/learn basic Forth, I recommend Dave's pfth. It is "standard" Forth with a few Propeller definitions added that let you manipulate the prop. It's pretty easy to find documentation and basic definitions.
Tachyon has many interfaces/devices built in which make it very useful for productivity. Pfth requires you to build the interfaces in the process learning Forth and getting used to the reverse notation, but it is definitely not as fast as Tachyon.
When I was first learning the Prop using the PE kit Lab Manual, I had some difficulty understanding the counters. Using pfth, I had to add the definitions for the counter registers, and define words to set or modify the 32 bit counter command. I was able to start, stop, and restart cogs, and by putting trial words for RGB LEDs and servos in 2nd & 3rd cogs while keeping cog 0 for interacting with the program while the other cogs were running (through the terminal) including defining new words. If one of the test words blew up in cogs 1 - 7, I could close that cog while keeping everything else running. It made it very easy to see what was going on and why things worked or not. Later I used it to understand how to interact with BlueTooth apps.
Tom
I am certain once you learn Tachyon it would be a breeze for your work.
Unfortunately I haven't had the time to wrap myhead around Tachyon, and now it looks like no time on the horizon. I re-entered the work force a month ago. Although its only 3 days a week, I am finding there is so much I no longer know, that I am spending the other 2+ days googling and learning
OT
Currently I am learning Python scripting for NotePad++ because we do a lot of copy/paste to html files for newsletters and the website. The biggest hurdle is finding the right editor items/objects and their syntax - they are basically Cintilla objects but wrappered by the Python script. And of course, Python is almost like other languages but just not quite. ie ":" at then end of if line, but otherwise idented like spin, "elif" instead of elseif, etc.
Now while I love the book, the Forth it is based on is very much a 16-bit 79 standard Forth, and now you are learning Tachyon, and Gforth, and now maybe Pfth, a subset of ANSI Forth. I love your daring Jon, but it is like page 211 of Thinking Forth..... too many variables
But certainly the reason you would like to learn Tachyon is the same reason why I wrote it, for fast turn-around projects. But not only that of course but also fast and compact with inherent debugging built in and the ability to interact and patch easily, even after the product has been "delivered", since there is always something major they haven't told you until it is being installed @#$!*&^!
Tachyon is non-standard because it is geared for the Propeller architecture which in itself is non-standard. Knowing the Propeller helps you know Tachyon because it knows the Propeller too as well as a lot of the peripherals that we are inclined to use. A standard "language" will never cut it for these real applications that we do. I see that you use DMX protocol and that's something I may add as well. The inbuilt multichannel PWM is good for many control applications and the super fast SPI instructions make interfacing to shift registers a breeze without dedicating cogs.
Btw, I decided to include VGA into EXTEND simply because it is easier for anyone new to Tachyon to have all these extensions already there, ready to use. I don't use the VGA output as a console in practice but it demonstrates that you can which is what would happen if you attached a PS/2 keyboard although personally I'm not a fan of limited Jupiter Ace type systems. I do use VGA for display purposes and right at the moment I've been inspired by the DIY anemometer to build my own RS485 distributed weather sensors and have these display on VGA monitors or other the Internet with my EASYNET server.
In fact since I normally run VGA from one of my small Pixie headshell modules over RS485 I then have the Pixie's Prop loaded with a simple bitmap graphics slave terminal software which also includes PS/2. Each module receives power over the RS485 line since I just use cheap 4-core TP phone cable and the SMPS doesn't care if it is 8V or 28V. Great for distributed displays.
Okay, getting my head around Forth. A couple of notable issues (Correct me if I'm wrong) as I see it:
- A serious lack of delimiter/textural formatting in the sources. A parameter looks like a command and vise versa. And when there is more than one command on a single line you can't infer from just reading that line - even when it's explained.
- No scoping. Everything appears to be globals. That's got to be name clash central! Especially when using multiple libraries/modules/objects.
It's going to be a while to get comfortable me thinks.
The title of the book "Thinking Forth" does not mean Thinking Forth Should Be More Like Other Languages, but it does involve thinking about a problem with Forth as the tool so that the problem can be readily expressed and simplified by using that tool the way it is meant to be used. As for parameters and commands that look alike, you are right, but what is the difference anyway? I have many parameters that are in fact commands but really in postfix Forth the final word (pun) is the command anyway. If I say 0 64 KB DUMP then KB is a command that is a parameter in that it shifts the 64 left 10 bits and the final word is DUMP which just expects a starting address and a count. Perhaps if it said DUMP(0,KB(64)) it might look more "natural" to many conversant in traditional computer languages but that doesn't make it better, although in this simple example, there is one you can run on the target processor from the serial console, the other you cannot.
The best way to learn in my opinion is to tackle a real job, not an example. That's the way I started when I decided to use Forth as the basis of the software and development etc for serial networked POS terminals in the 80's. I packed a lot of power into those slow 8-bit micros at the time which included scanning, and what I termed "electronic Journal" etc. Forth made possible what many at the time and even later considered impossible, and in a very short time. A team of C programmers that took over from where I (one person) left off still could not get the same functionality years later with better hardware and more memory.
From the outset I was determined that I should be able to program an application in fast high-level Forth without resorting to assembler in the app itself. So even timing critical devices such as the WS2812 LEDs and 1-wire etc can be implemented in Tachyon Forth without any need for PASM code, and indeed PASM cannot be executed from hub anyway and usually requires "spare" cog RAM or spare cogs, so it is something to be avoided on the Prop. So this is the case and if the bit-banging and SPI instructions aren't enough then there are the RUNMOD type modules for special uses as well as the ROMs which can be loaded into cogs. Of course, I could load an assembler module that takes up memory to assemble traditional style PASM source, but it makes more sense on the P2 with more resources. Tachyon is not about "PC language", it is a Prop resident environment that lends itself to rapid prototyping and development and also overcoming the speed/memory limitations of other Prop "languages".
EDIT: Anyway, the important thing here is that the user can create their own modules ... I hope. That way it'll be easy to port them from the Object Exchange.
PS: Peter, I'm commenting here because of the likelihood of Tachyon becoming a central part of the Prop2. I suspect Jon started the topic for the same reason.
https://aliexpress.com/item/weather-station-with-UART-port-with-cable-length-3-2-meter/32807830742.html
And I intent to use one of Peter's IoT5500+P8 modules to connect it to weather underground at wunderground.com as a personal weather station.
This gives me local backup of all data to an SD-Card if the internet/router shouldbe down.
And it will run on battery for power-fail protection.
Of course the code will be Tachyon using the NW-Module to send the data to the wunderground server.
This way I can add additional temperature sensors for my mango trees.
I am here in Spain at an altitude where nobody grows mangos so far -
but I had two successful harvests already. Just closely monitoring winter cold temperatures to see how hardy the different varieties really are. And when to start the sprinkler in the freezing nights to protect them.
And @Jon - don't be bothered by Tachyons 'non-standard-ness' just go for it.
And read lot's of Peter's source code.
That's how I got into Forth and it's great ...
Cut em in half around the pit, twist off, cross slice the fruit to cube them but leave them on the skin, and then shove it into your face
Any left over can be made into fruit ice-creams!
Re the weather station - That's a bit over the top plus I'd like to do my own. If however you want some lightning hardened isolated RS485 then say the word. I have two RS485 interfaces on a Puppy module, with solid-state isolators, soft termination, gas tubes, polyfuses, tranzorbs etc.
Just hooked up a DHT22 and fixed the routines so they don't lock up if one is not connected, and also improved the ping sensors. I was doing some tests on them and for some reason they don't seem to transmit those 8 cycles of 40kHz ping until about 660us after the trigger (like it is just waking up). I also used one as a detector to check the strength and took a whole heap of measurements. I'd like to use them as cheap sensors but certainly as proximity sensors anyway.
Here's a bit of code I am just leaving to run in a cog to ping distance in millimeters and read the temperature and humidity, with the results in global variables. I will incorporate all my sensors into this routine so the main program can just access the variables.
I know that "Easy" is a state of mind that I will achieve with Forth. At the moment, however, I am on the steep incline of the learning curve at the moment and, perhaps, grasping at straws.