Forthers - Can you really work well this way?
LoopyByteloose
Posts: 12,537
Okay, I am trying to get up to speed with PropForth and TachyonForth, but both threads are very long. I am not always reading online in real time.
At this point the PropForth 5.0 thread is 14 pages, and the TachyonForth thread is over 23 pages. And both threads are high in viewership.
What I am doing for myself is I am trying to print the threads into a set of PDF files, but even then I have to prepare multiple files to get all of them. I don't mind doing so, but I do wonder if there isn't a better way to preserve all this info.
Just maybe, some logical break point to start a new thread is being overlooked.
At this point the PropForth 5.0 thread is 14 pages, and the TachyonForth thread is over 23 pages. And both threads are high in viewership.
What I am doing for myself is I am trying to print the threads into a set of PDF files, but even then I have to prepare multiple files to get all of them. I don't mind doing so, but I do wonder if there isn't a better way to preserve all this info.
Just maybe, some logical break point to start a new thread is being overlooked.
Comments
Consider distilling out the questions from the conversations?
What I tried to do was to take the propforth thread discussions, and find each specific question.
Then an attempt was made to phase the question in its, simplest, most succinct term.
An attempt to capture the detail that caused the question was made, if this was not already apparent.
Finally, an explanation of the solution was given, with a mention of the governing functional requirement.
This was not always performed fully, nor was it done well. Some of the questions were too short and seemed trivial, some were too complex for me to answer well, and some were overcome by events.
If you could lend your "new guy" perspective to the threads, this could be a big step forward. Please feel free to ask for further clarification of anything you find in the threads, and please post anything you care to produce for summaries, questions and answers, anything you find. Your help is the cog that is needed to get this machine turning.
Eventually, if you could replace any of the crappy pages on the googplecode/propforth wiki, it would be greatly appreciated, by me, and anyone that need to read them.
You can include information on other forths as well. In propforth, there are at least THREE default kernels: The optimized Dev kernel, the SD kernel, and the EEPROM kernel. Then theres also the unoptimized kernels for generating new kernels. Each has a different function and a necessarily different word set. Tachyon and pfth, gforth, FPC, can all be considered in this fashion: FORTH, but a different set of tools for a different, specific job.
Feel free to explore any options, and document these in the propforth wiki as convenient.
But as long as I can print PDF files, this seems a way to review and condense useful fact and key issues. I'll see what I can do, but I have no idea where this will all lead.
I printed the PropForth5.0 and it requried 6 pdf files of 50 entries each. Parallax's software will only allow 50 entries to the printed document.
And there may be problems with code examples being inserted in boxes that don't preserve the whole entry in print format.
We will just have to see.
The only way to learn is to practice.
That mean writing lots of code.
Using Notepad or Wordpad start with simple words in your study file. (always save this file)
Copy your code from your file (select all and copy) Then in the forth terminal window. Paste it.
Test it.
If it does not work,, then you have to work out why. Thats the learning process.
The more code you write the more you learn.
Here is a word to try : debug st? key drop ;
You can insert debug at any point in your code and examine the stack. (Propforth).
People will help if you post any code that you are having trouble with, Don't expect people to write it for you though.
Ron
I started this practice fairly quickly. Recommended. It contains the words, and my notes on them, along with simple things like loops and decisions.
Thanks Ron.
I do understand what you are saying and I have been working through words in both Gforth and Propforth. But reading the threads offers a lot of insight into what is really going on and where PropForth or other Forths are at this point in time.
The six pdf files I printed for PropForth V5.0 thread represent roughly 125 pages of paper if I were to go to a traditional printout. I do admit it is not as dense reading as a normal 125 pages, but it is quite a bit.
For the Tachyon thread, I ended up with ten pdf files, maybe 200 pages of text.
I certainly will try to write code and ask questions, but I need to keep returning to basics to get my bearings and I certainly don't want to bore everyone with asking the same questions again and again.
I am making headway. It really doesn't matter if it is slow.
I am a Forth beginner as well, currently focusing on Tachyon. Maybe it can be helpful to get in exchange while we climb the learning curve.
I tried to get some attention with
http://forums.parallax.com/showthread.php?143244-TACHYON-OBEX-code-exchange
because I learn best by studying code and playing with it adapting it to my needs.
But there do not seem to many Tachyon-Forthers sharing their code.
My initial attempt to get a comparison here http://forums.parallax.com/showthread.php?141704-Comparison-of-Propeller-Forth-Implementations is on hold since I am only dealing with
Tachyon at the moment. Here I like to read the source and the kernel itself which gives me - slowly - some insight in the Forth-Thinking. And it's good for my PASM understanding as well....
I am working on PropBoE and ProfDevBoard - and would be happy to find s.o. for some code exchange (for beginners ...)
Peter's Tachyon add ons are great, but a little ;-) ahead of me.
I do understand what you are hoping, but TachyonForth is really beyond my skill set at this point.
Introducing yourself in the TachyonForth thread is your best bet for real help, if anyone is doing that. I personally have been studying PropForth as it is a bit easier for a new user.
I also wrote a HOWTO for complete beginners, but that may not apply in your case. Now I am trying to work through a comparison of "Starting Forth Lexicon" to PropForth, but it is not ready yet.
It does seem that Peter wants to get something working in Google Documents if you care to take on a leadership for that.
I do remember your thread on comparison and you did quite a bit of work on it. The problem is that comparisons tend to lead to huge debates amongst loyal users of one or the other.
BTW, in your comparison you were wondering about SPI. Both support I2C which is just a more complex synchonous serial - so both with do SPI as well - maybe with some adaptations required.
I just had discovered your HOWTO in the other thread.
Great for beginners - I am already a little beyond.
But your lexicon comparison will be a good start to add a column for Tachyon - maybe I can help there a little.
My primary interrest is not Forth in itself, but geting the best out of the PROP.
And yes - Tachyon has a very fast SPI implementation.
I should take some time to update the comparison with what I have learned.
One of the things I like very much about Tachyon ist the interactivity.
Even loops are executed without wrapping into a new word.
Hi again, actually getting the best out of the Propeller may be one of the better things about Forth on the Propeller as the code is rather transparent to the user. A lot of performance issues get demonstrated in a way that may be easier for some to understand.
Still, I'd rather not have to start from scratch everytime I use a different Forth, so I have tried to focus on what the lexicon might be.
I have created a comparison between Starting Forth and PropForth V5.03 (maybe the 64K eeprom version).
This is a rough draft at this time. After I get something good in PropForth, maybe I can do something constructive for everyone on TachyonForth. I am still developing a method and TachyonForth is evolving at a rahter frantic rate.
It might help you to consider visiting PropForth's Google Documents site and learning a bit about how it evolved from an earlier Forth on Propeller.
As I understand it Peter's TachyonForth was originally based on PropForth. And PropForth was based on Spinforth. SpinForth is not longer active as it was also authored by Sal Sanci.
Peter made some big innovate jumps, I suspect studying the conceptual contrasts between the two would be helpful.
http://code.google.com/p/propforth/
at the start of the Tachyon thread Peter writes the following - so I am not sure if this statement is correct: Peter will tell us ...
Anyhow:
Great start, your comparison:
I'd like to suggest to keep the $xxx ASM words in a separate table, to not clutter the list.
Alphabetical listing might also be not ideal for submodules like SPI / SD and the like.
There it might be better to just keep the module name in a 'modules' table with all words for a module in one place.
Otherwise it will be very difficult to compare PropForth to Tachyon. In those modules similarly named words might have quite different behaviour.
The comparison at the module level is what I was starting im my 'compare Forth' thread - and would be good to have here as well.
... Reading your doc I have also the impression a logical grouping of the words might improve readability/understandability.
Groups could be: Stack manipulation, math, logical, memory-access, IO, communication, ... within those groups alphabetical sorting is fine.
You probably have this in Excel or some edible form. I could start adding Tachyon words to it - after the proposed rearrangements.
Thank you for your review of Peter's introduction. I guess that I read too quickly and Peter seems to not so much as built on PropForth as to acknowledge that it has influenced his decision to creat Tachyon Forth. I made a huge mistake.
CogForth was the source of Tachyon Forth.
SpinForth was the souce of PropForth.
There was also a PropellerForth that appears now inactive.
And JDKForth is a compiled Forth that may or may not be active.
These comparisons get easier with a bit of practice. I am including a comparison of Tachyon Forth V1.0 to Starting Forth Lexicon. It just happens to be what I had installed on my Propeller Proto Board at the time.
The interesting think is that it appears that Tachyon Forth actually may be closer to the Starting Forth lexicon than PropForth.
I am not sure of what this all means for the particular versions actual performance, but it implies that Tachyon Forth may be easier for a new user.
These result are very preliminary. One big question is whether I am getting truly representative lexicons from both PropForth and TachyonForth. I am sure everyone will have something to say about this.
still find the alpha-sorted list hard to read - what Du you think about a structured comparison? - would make it a lot easier to compare things
ALL micro controllers are great for forth, just as all puzzles are great for solving, and cake is great for eating.
Prop is actually the closest (non-Moore) hardware to a hardware forth.
maybe i just like solving puzzles and eating cake.....
_aaaaaa
$C_aaaaa
$H_aaaa
are generally internal intermediate words. they are support overhead and should not be something we consider in our dictionary comparison. these only get touched when we change the basic structure of the kernel.
dictionary search is first, second is check if it can be interptrted as a number; this costs more than 2x ? then a dictionary search. since kernel uses 1 2 4 very often, these provide significant speed verus cost in memory (Sal' decision)
You pointed out the Assembly words as big distraction. In truth, I didn't know what they were as I hadn't gotten far enough to determine that their identity. Mostly I have been focusing on reading ''Starting Forth" and the "Forth Primer.pdf" as a means to gain entry.
There is a need to identify 'sub-lexicons'. And for that I may need some guidance. PropForth seems to have more as it has developed longer. But I really need to sit down and reaquire a more up-to-date lexicon for both PropForth and TachyonForth.
I'd be happy to provide spreadsheet documents in Libre Office (previously Open Office) or list in .txt files as means to assign groupings to words if you wish to develop some propsed groups. I was thinking of doing this eventually. My first goal is to be assured that I am using listings that are acceptable to all.
PropForth has a Quick Reference that provides some insight into how they view functional groupings. But I think it could be divided into THREE major headings - Core Lexicon, Non-Core Lexicon, Propeller-specific Lexicon. After that it could be divided by obvious functionality.
Also, there would inevitably be some introductory notes. PropForth has a rather unusal point-of-view about the Cell and what that implies. I think I have read that the Stack and the Return Stack are 32bits, but the Dictionary structure is 16bits. Conventional wisdom of the cell as the smallest unit seems to be violated and the concept of Double cell width obscured.
For automated comparison purposes, these list have to first be sorted and then compared. And that is an ASCII sort. But after than, I lot can be done to make them more humanly useful.
Assigning a group heading can be simply done by adding another column in a spreadsheet and tagging each entry with a subheading code. Thus, the headings are assigned to each word, one does a sort on multiple columns to get the more presentable results.
And so, can you offer a standard listing of sub-headings that might apply to both PropForth and Tachyon Forth?
math, logic, branching, i/o, text, and diagnostics. (and "internal, do not use")
this is in additon to the alphabetical list of words.
this could make many thing clear
Well removing those makes my job a lot easier. I will do so post haste and provide them in a Appendix.
if you flag the ones that you need elaborated upon, i can discuss them with sal and get the entries updated
Also, I find the whole idea of a 'Forth Word' to be a bit intriguing.
The "hard" definition is that a Forth Word is any item, one character or longer that has white space around it.
On the other hand, what I call the "soft" definition of a Forth Word actually has three items; words defined by the white space around them, words that are paired to create a beginning and end marker for a phrase of several Forth words or other data, and Forth words that expect to be followed by specific data (thus not following the RPN stack logic rule).
Feel free to discuss and offer suggestions, but the next phase of comparison may take a bit longer than it took to get this phase out.
So far, these sorts and comparisons have been listings on the 'hard' definitions. I actually edited the "Starting Forth Lexicon" away from the 'soft' definitions and into the 'hard' definitions for the sake of comparison.
But I think that the semantics are more obvious in the 'soft' definition approach. Leo Brodie had this right, but others have locked onto parsing whiite space as being overly important to presenting words. It is just the mechanics of parsing. Humans are involved and seem to intuitively grasp the phraseology if they are allowed to do so.
by functional group like plus 'stack handling' is most intuitive to me - and since we are close to the HW I would like to add modules for [SPI, I2C, Serial, ADC, DAC, PWM, Servo, ....] which are not really part of the original forth language, but make up the application vocabulary I want to use to build on. is obviously important
but is a design decission - there is some agreement in the forth community - but in a very restricted environment like the prop the application dictates what sub lexicons I want to include and which not.
In almost all the functional categories there will be Core and non-Core words - or basic and derived words.
same is true for Tachyon - and I think this is a direct result of the Prop architecture. Inside COG 32-Bit is the only thing that can be handled really fast. But for dictionary 16-bit is plenty. And when handling strings or byte arrays in HUB Ram we need to save RAM and do this as bytes - not wasting by using 16 or 32bit CELLS.
So my implreesion is the Cells construct is a legacy and we can adapt this to make best use of the PROP.
This is why PropForth and Tachyon provide the C@ W@ L@ (PropForth) or @ (32-bit Tachyon) and in addition the COG@ / COG! words.
this might help in storing the multi-dimensional aspect
ANS Forth 94, likes to designate what it considers most important and central to Forth as Core, and then adds on a mighty large bunch of etcetera.
What I was really thinking was NOT so much this concept of that CORE, but as the 'core functional items for the user' on the Propeller. I really don't want to go back to another debate on conforming to ANS Forth 94, but either I have to mention this and redefine CORE or find another term that is not so political.
I am just thinking of CORE lexicon as terms one needs to know; NON-CORE terms are ones that are nice to know -- both are rather less attached to the Propeller in concept and are more attached to Forth.
That's a lot of words to say that I am thinking something different for CORE than what the standards view.
NON-CORE is also a bit of a problem if you want to clump in I2C, 1-wire, SPI, ADC, DAC, and so on. I personally do not want to. To me, these all seem micro-controller specific which would more likely belong under PROPELLER SPECIFIC, neither CORE nore NON-CORE
There in lies a bugga-boo of what is Propeller specific. Some are internally specific to proper care and feeding of the Propeller; others are external to the Propeller and more related to driving hardware. So maybe another great divide between Propeller specific - internal and Propeller specific - external while Core would provide the bulk of what the user must have to use Forth and Non-Core would pretty much be optional items (like SEE or DECOMPILE, which are personal favorites on mine).
I made a PDF image of this thread so far and will muddle thorugh sketching out something over a latte tomorrow while I do a few other things.
I have a lot to do, so this will remain open discussion for at least a few days. I don't want to do something and then have to redo it all because it was no good.
Kernel words are the most used and time critical words, that are implemented in PASM in the kernel COG image.
Vs. non kernel words are implemented [mostly ;-) ] as byte code words and live in HUB RAM or on SD card.
Reloadable PASM modules being the exception here.
attached is a list of the Tachyon Kernel words Tachyon 2 kernel words.txt
and the non kernel words. Tachyon 2 non kernel words.txtTachyon 2 non kernel words.txt
Those could be considered the core words I think, since they are in the base image.
Extensions are loaded separately.
e.g. here the EXTEND words Tachyon 2 extend words.txt
A. Both PropForth and TachyonForth have different solutions to how their software is released. And both are evolving rather quickly. But please don't forget pfth if you have a strong desire for ANS Forth 94 studies with some unique Propeller usefulness.
B. The original purpose of the comparisons were to aid the new learner in mastering the lexicon. That is still the highest priority.
C. Everyone is looking at development differently.
PropForth has taken on producing three versions that are 32KEEPROM (no xtra storage), 64K EEPROM (xtra EEPROM), and SDcard (storage in SDcard), while TachyonForth has a different vision of SDcard use and seems not too concerned about extra EEPROM space being used. pfth is still active, but Dave Hein feels that most of his efforts are complete in that he has effectively presented ANS Forth 94 in C on the Propeller. To improve speed or enhance features might actually pevert and destroy what he has created.
I suppose that at a very early stage, the comparisons to the "Starting Forth Lexicon" become useless to some. At that point, the new learner wants to learn either the PropForth system or the TachyonForth system and need-to-know information specific to which version is as important as listings of lexicon.
All this I need to dig further into by reading and using. One area of contrast is how the Propeller i/o pins are manipulated. Nothing too difficult here, but PropForth and TachyonForth are indeed different and this is such a primary aspect that the new learner should be quick to learn which they prefer.
Change is the only constant.
I just visited the TachyonForth Dropbox site and see that TachyonForth is up to version 2.1. Also, Peter has been rather diligent about providing add-on lexicons that are purpose built, many for particular hardware .... but not always a hardware focus. One big item is an EXTEND.fth file that appears to be a more generalized expansion of TachyonForth. I suspect that I have to install Version 2.1 and the EXTEND.fth to get something close to a good view of possibilities.
The thing is that Peter is wise in that he wants to hang on to a small lexicon configuration as memory is limited. Providing more and more words is a rather useless objective if there is no space to develop a project on the Propeller.
PropForth is doing similar things, but not in the same way. For one, goals are different. PropForth has tried to tie choices to a group of Propeller configurations available.
So there have been the 32K EEPROM, the 64K EEPROM, and the SDcard images, not as much of a limited dictionary with add-ons. Plus projects have been more formally defined and more complete - the Jupiter Ace, the Spinnerette, and so on.
Version 5.3 of PropForth has a big commitment to interfacing with software in Windows which is extensively provided, Goterm and other items. All these items may be appealing to some new users, but might just suffer a bit from being too well-defined for entry level overview by users that want to develop much of their own systems. Ambitions vary and at times something has to be left for the user to dream about.
So with PropForth, a different kind of approach in locating the majority of useful learner lexicon is required. As I write this out, but am wondering where I should go and how I will find it. Maybe I already have.
For the most part, I am very comfortable with V5.03 and the added lexicon files included in that .zip file. plus the later addition of DECOMPILE. I am not sure what exactly is going on with 5.1, 5.2, 5.3, and beyond. But I feel that what has already been done in 5.03 and a bit more is quite mature and may be very stable. So I tend to think that I will be doing less in chasing version changes in PropForth.
The main conclusion is that I will NEVER be able to comprehensively document all the features as I am not able to build all the different versions and use them.
Also, improvements are inevitable - so I will always be at least one step behind.
The BEST that I can do is to empower more new users to get up to a certain level where they can mutually support each other's efforts. So I fall back my focus on getting the new to Forth user started AND getting more into presenting the salient feature of TachyonForth or PropForth or pfth as a bridge into the users feeling confident enough to help each other.
Full, comprehensive documentation of Forth is nearly impossible as there is no way to set a limit on lexicon or who revises what.
So I am now thinking of documenting at two of three levels
Level I - Needs to learn or review Forth in general before getting involved in a Forth on Propeller
Level II - Learner wants a version specific introductory presentation of Forth on Propeller
Level III - Learner has become a User and will seek mutual support from other Users/Learners and the originators.
So I will try to stay off the Forum tonight and really get something done.
1) Propforth v5.3 will be the LAST version of propforth for the Prop 1, barring any bug fixes. It contain the final implementation of all the developed experiments demonstrated in the previous versions. We don't have to worry about PF v6.0 until the Prop 2 comes out, so this is not even on the list yet. But a v6 would be designed to completely compatible with v5 code, and add things like software multitasking etc.
2) The difference between propforth and "standard" forth is about the use of the prop. "Starting Forth" is about learning forth on a PC, prop forth is about using a micro controller. There is no easy way in standard (ANS) forth to connect and control a servo or stepper motor, or to read an accelerometer. But forth is all about controlling embedded systems, why the disconnect? Because learning forth onthe PC and creating an embedded application are two very differenct things. Right tool for the right job.
The transition from Brodies books (learning on the PC) into developing embedded systems (ie using a microcontroller) is at the cross compiler. This is the advanced stuff at the very end. This is where you develop on the PC, and generate code for a target micro controller. The target has very different word set than the PC, since it does very different things. The scope is similar to the difference between pfth, and propforth.
You are being very patient me with and I may be a bit stubborn on my end. It is just that one hits a rather daunting 'wall of words' when one views the WORDS on their terminal or turns to your PropForth.htm.
I have been trying to find an easy way in to PropForth. "Starting Forth" only gets one so far, but it is rewarding and removes a lot of preconceptions. But one must make the transistion.
Your PropForth.html shows an incredible amount of hard work, but I hit a wall with it as it diligently catalogues all and everything - both the need-to-know and the eventual nice-to-know.
Nonetheless, there seems to be a very good solution that does NOT require writing more, but repackaging what you have.
The encolsed can be refined quite a bit to be easier for the user, but the main concept is there.
Today was a lot of fooling around with stuff for me personally. But I came back to the PropForth.html as the ONLY reliable and complete source document for PropForth Lexicon. It is all there and you keep telling me it is.
Still, I and other beginners need something that was shorter to work with, so I have taken a big risk and removed what SEEMS TO ME to be not required of the rank beginner. This is only a proposal.
Even as this is, it is quite long. Maybe the Table of Contents can be reduced to many fewer pages via a columnar listing of specific words (something like 4 columns on each page of the links to the actual entry).
Forth on Propeller 2 is likely to be an awesome resource, especially when everything is newly released.
The common catch phrase is that "you can write the words yourself'. However, you need to have a good understanding of how Forth works to be able to do this. I've been working with Forth for a little over a month, and I think I have a pretty good understanding of it now. Someone had suggested a few weeks ago that it should only take a few minutes to implement the [char] word. Well it took me a few weeks to get to the level where I could do it, and the solution is very simple. But it's something that a novice would struggle with. I think the experienced Forth programmers lose sight of how much you have to learn to really understand Forth.
I don't agree with prof_braino that there is no easy way for ANS Forth to connect and control a servo or stepper motor. ANS Forth does provide a way to embed assembly language. Or an ANS Forth interpreter could provide a few platform-specific primitives. It is still an ANS Forth interpreter, even with these extensions. The nice thing about using ANS Forth is that you can port your servo/stepper motor code to any processor. You just have to implement a few platform-specific primitives to get it working.
So the notion that ANS Forth can't do embedded is at odds with reality.
Links:
http://sd2cx1.webring.org/l/rd?ring=forth;id=26;url=http%3A%2F%2Fwww.mpeforth.com%2F
forth.com