Starting Forth Lexicon and what is different in PropForth v.5.03
LoopyByteloose
Posts: 12,537
Please see the attached.
I must say there were a lot of false starts to this and I really have been concerned that some people that have followed my HOWTO Learn Forth on the Propeller from scratch are rather dismayed.
This is a useful bridge between the two that shows what is left behind or the user will have to revive if desired, what is modifed, and what is simply renamed.
Please be advised that the comparison "Starting Forth Lexicon - Missing or..." included herein has gone through a 2nd revision that is posted further below and more revisions might be forthcoming.
I must say there were a lot of false starts to this and I really have been concerned that some people that have followed my HOWTO Learn Forth on the Propeller from scratch are rather dismayed.
This is a useful bridge between the two that shows what is left behind or the user will have to revive if desired, what is modifed, and what is simply renamed.
Please be advised that the comparison "Starting Forth Lexicon - Missing or..." included herein has gone through a 2nd revision that is posted further below and more revisions might be forthcoming.
Comments
I thought you you were covering this in the forther's thread?
In any case, I don't think you've completely stated the purpose and goal of the exercise. This I believe is something along the lines of using the traditional forth text "starting forth", the general ANSII forth definition (which generally is NOT applied to a microcontroller implementation of forth), and a specific forth on the propeller (maybe propforth).
So there's at least three aspects that should be spelled out, and brought together before the noobie is thrust into the fire.
Geeze, there's a lot of work to get the easy part set up! Is it necessary that the material be spread over three documents, or would this be better in a single resource?
Have you gotten any input from a newcomer? That's what I'm hoping to see.
Let the Forther's thread die. It has gotten too long for new users to want to bother with it. They are attracted to short, precise information as a clear entry point is shown.
First off, everyone says that "Starting Forth" is a great text and the best place to start, but nobody has been rigorous about reviewing its content in light of what Forth on the Propeller requires and offers. I am taking a teacher's point of view and investigating if the content is worthwhile and how the Forth language evloves into 32 bit 8 cog architecture.
I begin to wonder what the Forth, Inc. created SwiftForth is like on a 32bit or 64bit platform as a lot of maths either increases absurdly in precision or is dropped along the way.
One very clear conclusion is that the whole 'Double cell' sub-lexicon is being dismissed on a 32bit stack machine as pretty much unnecessary. Does the Propeller really need to deliver 64bit maths?
And then, there is something that PropForth is doing quite differently in word creation.
Traditional word creation has four approaches.
1. the colon/semi-colon word as a means to extend the language in many directions
2. Variable as a means to dedicate a cell to a variable (and 2variable for a double cell dedication that is part of the double word issue).
3. Constant as a means to dedicate a cell to a constant (and 2constant for a double cell dedication that is part of the double word issue).
4. And finally the Create that PropForth has decide to do something very different. Traditional Forth has the Create ---- alot --- cells for the construction of an array. But it appears PropForth is using Variable -- allot --- cells in lieu of Create. And, the Create --- does> is non-existant in PropForth as there is no word Does>.
For #4, I have no idea of what the actual reasoning for change is and I also we we have Wvariable and Wconstant in PropForth. I wonder if Wvariable will produce a 16bit array.
So I guess what I am saying is that I am finding this a very worthy comparison though it may look superficially naive. It has given me quite a few clues into what Sal Sanci considers less important in PropForth and what the student of "Starting Forth" can best pay attention to.
It also shows quite clearly that ANS Forth 94 had no real vision of a 32bit microprocessor when the standard was written.
I opened this independent thread so that this comparison would have focused viewing and discussion by every form of Forth on the Propeller -- especially any new users that really need good info right away.
I am NOT so much as trying to promote Forth on the Propeller as to learn it and to learn how it differs from Forth on other platforms. The differences will lead to Forth on the Propeller being judged on its own merits, not the hubris of touting faster and faster. Or whatever one chooses to tout (funner and funner?).
Spread over 3 documents? I am not sure which are the 3. I guess in a PropForth context it would be the HOWTO learn Forth on the Propeller from scratch that I wrote independent of any particular approach. This is a transistional phase comparision that specifically targets PropForth. So does it go into the impartial HOWTO, or does PropForth want to include it in their documents? I dunno at this point. And then there is the PropForth.htm.
I guess I am saying "yes" the 2 documents are quite necessary to be fair to the beginner. I need to run similar comparisons of TachyonForth and pfth if I were to consolidate the data into just one HOWTO document in an impartial way.
And I have offered to let other's decide how they want to present the transistion from 'Starting Forth' into a particular Forth version on the Propeller. But nobody seems to know how to do so or wants to do so. I am just plodding along after what seems to be educationally helpful -- real facts found from real data rather than just an enthusiastic tutorial that recycles what everyone else has said without due consideration.
This thread is intended to be very specific to new learners of PropForth.
I really like the "does>" word. It basically creates a new type of variable with unique properties. It's a nice way to create arrays. Supporting "does>" in the interpreter does make things a bit more complicated. A variable needs an extra pointer in it's header, which is normally unused, except when a variable is declared with "does>". I'm still trying to figure out how to implement "does>" without the need of an extra pointer in the header, except when needed.
Can you shed any light on the missing POSTPONE?
These are most concerning the prop's smallish RAM available for dictionary entries.
Sal selected a threading model based on experience implementing forth on various processor, and several experiments on the prop itself, the first of which was spin forth. The decision was made that each entry must consume the absolute minimum space that still permits function. The details are laid out clearly (to someone who understands threading models, I get lost about half way through) in the comments and in propforth.htm. One result of the various decisons affects CREATE. CREATE "starts" a dictionary definition. CREATE is Primarily used to create new forth word dictionary entries. It is used in the the exact same way in propforth in this role, it starts a dictionary dfinition, the result is used later by the word that completes the definition. HOWEVER, the details of the implemation to don lend itself to the SECONDARY use of create, which is creating variable arrays etc. The Intermediate finction of tradition create leave the START address of a diction entry on the stack. This is not done in propforth, as the address is not even used in propforth. Rather than make the every dictionary entry one long greater, and slow down the interpreter with unnecessary steps, Sal use a different method for his threading model. We discussed this, the consequence being the we would have to use VARIABLE to start an array, and there would be no support internal to the kernel for the CREATE ... DOES> construct.
CREATE ... DOES> makes a definition that has a compile behavior, and a separate run time behavior. We had noticed that this construct is one of the biggest causes of issues in forth. EXPERTS can do amazing things with this construct, and non experts can produce disaster. Rather than leave that particular booby trap for new comers, we decided (at my insistence) that it would be better to go with the custom threading model and require separate compile words and separate run time words. IF YOU MUST HAVE CREATE... DOES> , you simply write an extension that implements it, and boom, you have you compatibility. But it would take a bit of work re do the kernel architecture to support this in the kernel, this is left as a exercise to someone learning kernel mods.
POSTPONE - what the heck does postpone do anyway? let me look that one up I never use it.....
OK ...... DPANS A.6.1.2033 POSTPONE says this word is used with the COMPILE process for immediate words. That explains that.
Propforth has a custom compiler and does not implement immediate words in the traditional fashion. There is no context in which to implement this word at this time.
SO WHAT DOES THIS MEAN to us?
IF we want to implement ANSII DPANS94 compatibility, we have to d a little work. This will increase dictionary size and slow down the prop. That's OK, if compatibility is the primary goal. IF fasted most efficient execution is the goal (which is Sal's design goal) there is a conflict. The solution, then, is to implement compatibility extensions, these can be applied to the basic kernel during the learning phase, and omitted when the student moves beyond beginner, or inserted into a modified kernel when the student moves to the advanced stages.
Dave is already quite capable, and has implemented the CREATE .. DOES> construct. Here is my suggestion, this might be a handy way to do this.
1) implement CREATE ... DOES> as an extension, using Dave's code, or ask really nice and maybe he'll do it for us.
2) Optimize the CREATE ... DOES> extension from high level forth into propforth assembler
3) Set the optimized version to reside in EEPROM or SD, and call when needed using the Paged Assembler method.
4) When CREATE ... DOES> is called, put the resultant code into the filesystem library. Now any CREATE .. DOES> defined words can also be called from the pages assembler, and there is zero impact on the propforth dictionary memory footprint, is executes at assembly speed, and there is no limit to how many definitions added (no limit up to the size of the EEPROM or SD card).
5) Any large ARRAY, set these to live on the SD card. Just call 1 to 3 blocks into memory, and work on those, write them , and pull in the next chunk. The over head of the transfer is is minimal and actually works out to be faster with less resources than adding external SRAM etc. (that overhead of the SRAM support tends to negate all the speed advantages)
OF course, these are just suggestions. The design decisions are completely left to the implementer. Just be aware that the more we deviate from the standard (either DPANS94 or plain vanilla propforth) the more work we have to do to get everybody on the same page (as we see here).
Remember the primary goal of DPANS94 is compatibility across ALL platform (which is by definition just a goal, ut known to be impossible due to architectural differences), and the goal of Propforth (and Tachyon) is the best efficiency for the task at hand. And Tachyon is kind of aimed at bit banging, and Propforth is kind of aimed at multi-processor applications.
This is getting really interesting!
Okay, I do get the general idea that this all allows a more compact Forth on the Propeller. That is in and of itself very interesting.
To a previous Forth user that is looking for sign post, not explaining the changes might make them wary. One doesn't have to go into all the detail, but an synopsis in introductory descriptions of PropForth would be helpful.
And I do see that TachyonForth appears to have followed PropForth's leadership and done the same. I had previous said that TachyonForth had built on PropForth and this was challenged by MJB. But now I really have to wonder if I was right in the first place.
Postpone.... I am all ears. Maybe Dave Hein can offer some informed opinion. The contrasts between the traditional and the modern are really rahter exciting.
BTW, please read the new revison and let me know if I still have errors to address. The simple truth is I am still trying to learn Forth and not all of these Starting Forth words that have been omitted make any sense to me. I guess I have to get backing to studying one more time.
I also thing that the fact that arrays require an alternative method to create them should be part of the documentation for PropForth if it isn't already. Do we add a whole section 10 to the PropForth.htm to discuss the contrasts between what was and what is? Or do we do a separate document for now and decide later if it needs to be included?
I really like the comparative lexicons and think they are a useful tool for both learning and for moving from Forth implementation to Forth implementation. At some point, details can be fleshed out with cookbook examples and code. "You are using Forth X but want to do this in Forth Y? Ok, here's the differences and here's how you could implement the words to accomplish the same thing......"
I think a Cookbook like document is needed for Forth in the style of the classic O'Reilly series (Maybe Forth in a Nutshell too?). This could cover the items that aren't part of the language as provided but nice to know about. People often have some idea of what they want to accomplish in a new language they are learning but the weight of the newness hides the solution from them. When you are in that situation, a cookbook often helps get you started down the proper rosy path! This could also become a home for the examples - how to I2C, SPI, drive a servo, ping a PING(((, etc.
Could it just be that you have never used POSTPONE because PropForth doesn't have it ;0)
Try Chapter 11 of Starting Forth as Forth, Inc.
http://www.forth.com/starting-forth/sf11/sf11.html
It is about 'extending the compiler'. Maybe PropForth doesn't do that.
: postpone ' , ; immediate
: ' postpone literal ; immediate
LITERAL is an immediate word, so it would be executed immediately if POSTPONE wasn't specified. By specifying POSTPONE before LITERAL the word is compiled to contain ' followed by LITERAL.
As you can see from the definition of POSTPONE, all it does is get the execution token for the following word, and then writes it into memory using the , word. These two lines could be added to PropForth to implement POSTPONE and .
This si a good idea. I'm kind of letting you create it, since you are closest to that user. Someone like me is too familliar with the new stuff, and loses sight of what a new person is looking for.
Will do, have to help repaint a kitchen before I can come out and play this weekend.
I put that in already a on a couple wiki pages, but the those are too many and poorly organized. We should delete that $41t and just concentrate on propforth.htm maybe.
I think we should start by trying a new section 10 as you suggest. the infor should all be in one place, Sal is focused on propforth.htm, and is looking to us to lead on the doc as we see need.
If we keep discussing in the threads, and you keep condensing the discusion into a doc of answers, we might end up with something good . You are very good in this role.
I may be very good in the role because I really haven't understood Forth. I certainly am not closest to the user. I AM closest to the beginner. That means somebody has to provide me with good info. I really can't figure this out alone -- too uninformed.
I think last night's rereading of Chapter 11 of Starting Forth just began to explain the idea to me of what an 'extendable compiler' is and can do.
It helps to go back through Starting Forth and take each chapter on its own as a separate topic and to make sure one has complete closure on each topic. After the first reading, one can use the Starting Forth Lexicon to determine which chapters are most in need of restudy. The student will see a lot of words they cannot recall.
And I now see that DOES> and POSTPONE are in part withheld because.....
A. The code is more complex and space consuming
B. Most users get into a lot of trouble using the extendable compiler features.
While I can sympathize with A, I find B a bit sad. It seems to say that PropForth (and TachyonForth) are not going to include all of Forth because these versions are 'baby Forth' version.
That may be a bit harsh. At least you say that the full version of Forth can be created by the user if they must have it. (But I am not so sure the user can easily do so.)
I may be very good in the role because I really haven't understood Forth. I think last night's rereading of Chapter 11 of Starting Forth just began to explain the idea to me of what an 'extendable compiler' is and can do.
I am not yet to the point of adding a Chapter 10 to the PropForth.htm. This has to be really informative suplimental info. I suggested it may eventually be considered. It seems I haven't really graduated from Starting Forth to PropForth quite yet. Those last two chapters of Starting Forth need to be mastered before I can really see the implications of not DOES> and no POSTPONE.
My greatest skill may be that a reread and re-edit my postings to the Forth threads. A lot gets lost in sloppy quick replies (hint... hint)
And don't forget, we need to clearly document HOW TO create Arrays. The topic has been kicked around, but I am not sure anyone has every done this successfully in PropForth. I certainly haven't.
I suppose that one day.... maybe soon.... I will find a way to do the entire Starting Forth in PropForth as a personal study project. It would certainly make me feel that I know something about PropForth vs. other Forths.
Thanks Dave, your work with coding ANS Forth 94 in C is providing a valuable added point of view.
It is time for me to print this thread in a PDF and to sit down and re-read it all until I really understand what's what.
So far I have been mentioning items the Starting Forth teaches, but PropForth omits.
And then there is are rather long list of NON-ANSI Forth 94 words that PropForth provides.
I don't want to try to request all of them in one go -- but one word does stand out
lockdict
I know from previous experience that the Cogs have locks and unlocks. I have never been too clear about those, but I think that they are about allocating the right of a COG to use a specific portion of hum ram.
This is a different beast and there are lock, unlock, unlockall, 1lock, 1unlock, 2lock, 2unlock, lock? sd_lock, and sd_unlock.
I do know that key has no relationship to this - it is tied to what I will now call the standard input. (emit would be tied to the standard output, and there is no separate standard error output).
These seem to be a 'mixed bag of locks and unlocks' -- some maybe required by Propeller hardware, others seem to be for something else. And the lack of symetry is a bit worrisome - what about unlockdict?
Of course, there must be some underlying rationale. But I have yet to locate it. If it is documented in the PropForth.htm, please just point me to the right secton number.
Oh!, don't forget _lockarray.
The point is that all the above implies there are 4 regions that are possibly locked - cogs, dictionary, array, and sdcard.
Is that all?? Are there more?
There is a substantial argument in "A beginner's guide to Forth" by J.V. Noble that maintains CREATE ... DOES> is of primary importance. This may have been dismissed too lightly.
http://www.computer-books.us/forth_1.php
Everyone says they want speed and space on the Forth, but at what cost?
Arguing that it is merely a compatibility conformance issue that should be ignored is just plain wrong.
The other locks serve a similar purpose but for different daa structures. I don't have the source handy but they can all be found with their counterpart unlocks and the structures they protect.
I don't think ANS forth has provisions for multi-threading as part of the core words, therefore no locking words are required.
What I don't see is an UNLOCKDICT in the PropForth.htm
And many of the listings in documentation are empty or vague.
What you imply is that PropForth is a multi-threading Forth. If so, that would need to be declared and clarified so as not to confuse new users, would it? I thought PropForth was merely parallal processing, not multi-threading - though I can see were the two mght get mixed up in dictionary and storage areas. PropForth has but one dictionary.
Thats what I meant, bad typing here.
That will be you with you r questions, and the rest of us with our responses.
Hence the process. I can't figure it out alone either, nor can I figure out what "good info" means until we go through the whole exersice of asking the questions, answering them, and making learning instrction, and trying it out on a new user.
[/QUOTE]
You are incorrect. Propforth CAN include these words, if someone finds a need for them, and takes the time to implement them. Sal does not need them, and has a bazillion other things on the to do list that must come first. If we want additional words, we must write them, or wait till someone does our work for us.
The "full version" is whatever each user decides is the full version. Your goal is to learn forth, the exercise that demonstrate that you have succeeded is when you produce that veriosn that you need for you goal. You are writing your target application.
Yes, this is my greatest weakness. I forget, and little tangents get overcome by events. So I need another set of eyes to read and make changes.
Sal provided many in the examples and extensions. caskaz has bunches of example, brian, and nick have example in their code. Every forth references shows how to do this, the only difference in propforth is instead of CREATE, we start with VARIABLE, and allot the required space following that. The variable becomes the 0th element of the array.
Try it out and let me know if it makes any sense.
One could certainly do this and get by. But there are exceptions that pop out and bite you if you don't lock the dictionary. Therefore, the recommended process is If we ALWAYS do this , we never can get burned by NOT doing it. This decision was reached after years of observing root cause for issues.
This is a flaw in the way we prepared the releases. At some point, we require that the user read the code, and work through the examples, in support of the rather sketchy docs.
If you look in the code for any instance of lockdict , you will see that it is followed by freedict. The assumption was that anybody interested (probably nobody) would look in the code to see how the word was used, and be able to "do the cypherin' ".
The problem stems from our inability to do all the docs up front. This was a known risk, and now we have to deal with this, the obvious consequence. The intent was that folks would work through the docs, and examples, and code, in parallel. It was also assumed that anybody interested in propforth would not particualry care about the DPANS standard, since most of the stuff we didn't include was determined to be irrelevant to using the prop. This was the 90/90 solution. We figured that this method would give 90% of the folks 90% of what they need, and they could ask about specific questions as they arose. I think I wrote this in a wiki page, but that turns out to be the part of the documentation that folks tend to skip. Maybe its time for a new strategy.
There are tons.
In any case where the explanation in propforth.htm is insufficient; we have to look in the source code. Once we find an occurrence of the word being used, we have to look at the code and trace through. From there, we (asker + team) have to write documentation to explain whatever we are asking about. Sorry, that is all I got. There isn't enough man hours for one and a half people to answer every possible question in advance, so we didn't. Answers to specific questions are to be driven by the asking.
All the words above are defined and used in the source code. That is where we start.
There is a "standard console" in v5.3, but there are some details to be aware of. Any errors sent to console are only displayed if a console is present and defined (by the user). As you can guess, we have not documentation on the details of this, as its just been worked out and nobody has asked about it yet. We can ask this after the kernel is released.
Back to CREATE ... DOES>: the function of these words is implemented, but in a different way, more convenient to the prop architecture, and Sal's design decisions. Tell me what function you need to define, and we can try to work through it. If CREATE - DOES> did exist, what defining word would you be defining?
OMG! Tons of locks and unlocks? Or do you just means tons of new vocabulary?
Which presumes that the new user knows all the lexicon and knows how to read source code. You keep arguing that you don't have to teach something because the new user can learn the same way the Forth experts created the code. I beg you not to do this.
I went to the standard output, standard input, standard error output model because phases such as "EMIT prints a character" is a bit confusing to some. It is a bit like handing a cellular phone to an aborigine and say, "Dial this number"... there is no dial.
It seems that PropForth and Forth in general presume a 'dumb terminal' and so the standard i/o phrases are much more clear as one not does have to ponder physical things.
I can accept that there is a better way. In fact, having a better way is rather exciting and interesting. I just began to be concerned that we were getting something less that all of Forth -- say 3/5th of Forth. And that would be 3/20ths (or some other fraction), not a true Forth.
It would be rather tedious for me to have to come to you for each and every word I might suddenly desire. And at this point, Sal's design decisions are somewhat undeclared to public view - one must reverse engineer all and completely know Forth to discover this 'secret sauce'. If you do want a word to resolve, how about :noname. It is a rather exotic and interesting one.
I was beginning to think that the format of the Dictionary did not provide the 3 flags that are provided in the original Forth, but they seem to be impleimented. I am not sure if they are implemented in quite the same way as I would have to do a Dump of some words and ferret out which bits, bytes and words are doing what. In the Forther's thread you mention 4 identities - F I A X. (Forth, Immediate, Assembler, and Executable). I am a bit puzzled by F as all the words are in Forth.
From what I can make out, 3 flags in combination would offer us up to 8 different options. And I suspect the 3 flags are representing are the following: 1. Execute/compile, 2. immediate/not immediate 3. unnamed words/named words.
There is actually a Forth word called :noname that I am sure you will say is too advanced for me. And maybe you are right, but can one create this?
You keep saying PropForth found a 'better way' to do something. If so, that is likely its biggest attraction and should be shown to everyone. The Propeller itself has shown that there is a better way to do micro-controllers. This kind of information should not be withheld even if it seems too advanced for beginners. We have a lot of smart people reading these threads that might participate if they really understood. And they might doubt your judgement.
Hopefully, you can see that what is lack is a 'teaching methodology' and that you have presumed some sort of magic grass roots approach if you just wrote enough documents. Documents need to have their own merits before people will invest time and effort into reading code and ferreting out hidden details.
here is some great description:
Some interresting links
A Beginner's Guide to Forth (HTML) see chapter about CREATE DOES>
Old, text-only version
List of on-line Forth tutorials, with links, other stuffLinks to various Forth-related sites
The ANS Forth Standard Document
draft v. 6, in HTML format ...in *.zip format
Forth system and example programs
Tons of stuff I don't know.
Sorry, I didn't mean to say any of that. I assume that new users know nothing, and I will never be equipped to answer all possible questions in advance. So we decided to put some general info, enough to get folks started, and let them ask specific questions as they go along. Pretty much like we're doing. I'm also trying to get you (and any other new folks with communications skills) to log your notes and share them. User questions drive the documentation,but organizing and publishing the answers is not my big skill.
All the aboriginals I met already had iPhones. And I still had a Nokia.
The process should be:
- type emit in the command line
- see if you can figure what happened
- repeat the above ten times with different values on the stack, it should take about 30 seconds
- look in propforth.htm
- ask on the forum or on the wiki or PM me or open an issue
It might seem cumbersome the first couple times, but after you learn the rhythm, you should find you can figure out most words really quickly
Its not a "better" way, its a different way, that somebody think is appropriate to this part. Stop worrying about "true forth". Your making yourself crazy. There's no such thing, there's only whats appropriate for this task.
Forth, like English, doesn't come out of a book. English comes out of someone's mouth. If we want to talk to the person, we have to figure out what the heck he's talking about, even if is ebonics.
Ask the command line, and ask propforth.htm. I'm telling ya'
Not all, but pretty much yes
No, you only need to care about the words you need to use at this exact moment.
Don't know, too advanced for me, never figured it out, no need yet.
"a different way that works on the prop"
True. If we ask such an advance question from a beginner perspective, the answer won't make any sense. And because we don't understand the basics, we would question the design decision, and run off in the wrong direction. When we know the basics, we can understand the answers to the more advanced questions. Don't try to eat the elephant in one byte. Life is too short to hurry through the good parts.
There certainly is a lack of teaching methodology on my part. I believe the solution to documents is your questions, and your notes.
You use 'lockdict' and 'unlock dict'.... I just located 'freedict'. YOUR phrase 'unlock dict' gives me 'UNDEFINED WORD dict'
My previous request for a clear explanation about locks and unlocks was quite sincere. You have requested that I provide a complete functional break out of the PropForth v5.03 lexicon and then this kind of stuff.
Clairty..... please! There is certainly nothing wrong with saying "I don't know.", there is something of a bizarre tangle that occurs when you use another phrase that appears to be PropForth lexicon.
It isn't about the true, pure Forth. It is about the rather large corpus of texts about Forth written before PropForth came to be and I'd have to call it 'typical' or 'somewhat typical Forth'
The less words that change, the better
Test such as 0> and 0<, there is no reason for adding 0>= when that is 0< or 0<= when that is 0>.
Similarly when loop+ is the norm, why go to +loop?
And when you have Lock and Unlock, why use Lockdict and Freedict? I looked and looked for two days for Unlockdict.
When you say I should just read the source, it means nothing to me without referring to the corpus of material that is typical Forth. And so every time something is NOT typical, I have to find out 3 things, not just one ... a) what is typical, b) what is the PropForth way, and c) what are the implications.
I suppose I could just learn the PropForth way and no other. But the learning would be slower and less thorough. It is not something I want to do as the end result is not as rewarding to me. I am willing to do the extra work as I really see Forth as fun and useful on any platform.