prof_braino, I think Loopy is suggesting adding all the words in "Starting Forth", except for those in chapter 3, to pfth. His last sentence suggested that PropForth and Tachyon might benefit from this also. However, I understand that standardization is not an objective for either PropForth and Tachyon. Something as simple as TRUE is trivial for somebody else to add if they need it. Other words may be a bit more complicated, especially if they require knowldege of the structure used by the interpreter for dictionary entries.
Personally, I think there is a lot of value in supporting the words used in "Starting Forth". I learned Forth by following the exercises in "Starting Forth", and I think it is an excellent approach.
Seems to me a delta set of definitions would work well here. Leave the Forths on their current path, but provide the ANSI definitions separately for those wanting to work through "Starting Forth"
The only real instruction then being precisely how to incorporate them prior to working with the book.
Well, I got about 4 gig free on my sd card. Someone could take each word, and implement the ANSI word in propforth.
Then map each definition to a block on the SD. With a jump table, load the block for each word, as its called, on the fly.
Then leave the result on the stack, and forget the definition loaded from the block.
So it wouldn't' cost any dictionary space, aside from the jump table.
And it would execute almost as fast as a regular dictionary definition. The speed of the SD is about what the prop can handle.
So its doable, does any one want to give it a whirl? If it works, the same could done for Tachyon. But there's a whole bunch of words we're talking here.
prof_braino, I'm a bit puzzled why PropForth doesn't already implement the ANS core set. It seems to implement most of the words. I typed the words command in PropForth, and I counted 373 words in the list! I looks like it has 97 of the 133 ANS core words, and 11 of the 45 core ext words. I don't think it would take much effort to implement the remaining 36 core words. I think the hub version of the ! and @ words would be the ones to use for ! and @. It doesn't make much sense to make the COG version the standard ones. You could run the chkcore.fth and chkcorex.fth programs in my latest zip file to see which words are missing. You would have to implement the "source" and "type" words to run it, but those should be easy to implement. You might be able to use ansi.fth to implement some of the words.
@David
I got a chance to build pForth yesterday and had a a play. I for one am all in favour of an ANS Forth. However Forth is only worth doing if it can take advantage of the unique architecture of the Prop Chip. Speed is not an issue (for me) if inline PASM can be included in a Forth word. It may be time for a re-think now you have the single version up and running. I really do hope you stick with it. Well done.
Tachyon and JDForth, are implementations that target the special requirements of the authors.
Propforth is is supposedly a general purpose Forth for the Prop. but it is not as robust as it is cracked up to be. It is fragile at best when passing data between cogs via the shared dictionary. The sd_driver when loaded (including the SD cog buffer) leaves only 4 longs (maybe 6) free in the cog. Thats fine, but try passing data to the driver from another cog via the shared dictionary. there are other ways but they are messy. The SDFS is really limited to running a few scripts. IMHO
There are tried and tested robust forth compliers out there, Portable Forth, pForth, being just one.
Hello to all,
My experience with getting started as a beginner in Forth has been a bit of a train wreck this past week. While a lot of well-intentioned and knowledgible people have tried to contribute, there are some very simple and clear facts.
First of all, ANS Forth 94 is not so much an issue as the lexicon of 'Starting Forth'. The beginner needs ALL the "Starting Forth" words to be supported (not all of ANS Forth 94) to acquire enough knowledge to build off of. If anyone chooses to leave them out of their own personal version of Forth, that version is rather useless to new learners.
The new learner can work with GForth, a demo of SwiftForth, or a lot of other Forths; but it seems rather foolish to send them over to another version when they expressed interest in learn it on the Propeller and in your particular version.
The situation is really rather odd and interesting. Many of the most adept users learned Forth decades ago. And like any natural language, the user has evolved and no longer desires to use less expressive ways to communicate that they had to use to acquire the language.
But, there is really only one text for new learners. It is 'Starting Forth' by Leo Brodie. People think that they can skip this text and merely teach the user on their own. A lot gets omitted. Or the learner is learning something else that really isn't as empowering as the original.
I have suggested that we exclude Chapter Three as it is all about storage that is not currently supported in Forth on the Propeller. But I missed the fact that the parenthesis are presented in this chapter. They are quite important to documentation. So far, these -- "(" and ")" -- are the only additions to the list, but as I read and reread the text, I may have a better list with a few more additions.
What am I trying to do?
Simply I am trying to help everyone that has created a version of Forth on the Propeller to have a simple way for increasing its use and popularity. That means making sure the new user has an easy, simple, and clear path to getting started. Even users that have learned it and want to review can use "Starting Forth" and the "Starting Forth Lexicon" to identify what they need to bone up on.
I do know this all sounds a bit pedantic, but after many years of teaching I really do feel that this is the only way to go. Most of you are very busy enjoying computing at a high level and don't realize that a new learner sees just a wall of jargon and mumbo-jumbo. They need a clear pathway into the subject. For C, that still is Richie and Kernighan; for Forth, that is still Leo Brodie.
Yes, there are words like PAGE and U.R and TRUE and FALSE that don't seem to be important to you. But if you work through the text exercise by exercise and chapter by chapter, they make very clear what Forth is and can be. At times I also am finding SEE extremely valuable, but it is NOT on the list, so don't worry about it unless you want to.
You can continue to omit these words or use alternatives as you like. But you make it harder to get wide interest and support for your particular efforts.
Fortunately, "Starting Forth" does not include .S and so, PropForth can at least avoid issues over ST?. I am pretty sure people will understand that having case sensitive FORTH allows less bytes to be consumed in a tight memory budget.
But asking an adept Forth user in 2012 to teach a rank beginner without reference to a basic text is just never going to work. The results are brutal for everyone - both the mentor and the student. Polite beginners will just give up and go away; others that really want to learn and are tougher are going to behave pretty much as I have done in the past week. And that was not fun for any of us.
So keep it simple. Insert the modified Starting Forth lexicon or at the very least, make a comparative listing which points out what is missing and what is called something else. And if somebody wants to learn, refer them to "Starting Forth" with the firm suggestion that they have to learn ALL of it before you can really help them with more advanced topics.
In closing, ANS Forth 94 is a whole separate topic. Treat it as such.
AND to Dave,
I would eventually love to sit down with your early C code for pfth and read it to learn more about both languages - C and Forth. Even it that doesn't run fast on the Propeller, I suspect it runs fine on other platforms and it very informative to someone that wants to learn more than just Forth.
Okay, after taking the time to read all the responses to my first mention of "Starting Forth Lexicon without Chapter 3", I do see clearly the issues of using a generalized ! and @ on the Propeller.
The fix is quite simple - just make a list of what should be used instead, with your own wise explainations. It may be that only pfth will ever fully complly with "Starting Forth" or it may be that none of the "Forth on the Propeller' varieties will be capablable of doing so.
Still, I personally have needed "Starting Forth" as an entry point. And I feel strongly that many others do too. So please ponder a smooth transistion = and don't get too fancy. Let Leo Brodie do the teaching.
prof_braino, I'm a bit puzzled why PropForth doesn't already implement the ANS core set.
Why... because they don't apply to the prop, in the eyes of the guy that doing all the work
... I don't think it would take much effort to implement the remaining 36 core words.
Anyone is free to implement any words they want. The fact that nobody has noticed these missing up till now and decided these are worth implementing, is evidince that they are not needed, and not missed. You are correct, it is a mostly trivial effort to implement these words. I invite anyone to do so, I will at them to the "ANSII Compatibility" extension set, that I planned to do when all the high priority stuff is complete.
I think the hub version of the ! and @ words would be the ones to use for ! and @.
That is a valid choice, but we decided it is the incorrect choice for our purposes. You of course are free to define anything any way you want. But remember, the standard is the "yardstick" and not the object we are measuring; those words ! and @ are simply WRONG. These are only used when there is ONLY ONE POSSIBLE CELL SIZE. As on a byte address able ONLY machine.
You could run the chkcore.fth and chkcorex.fth programs in my latest zip file to see which words are missing. You would have to implement the "source" and "type" words to run it, but those should be easy to implement. You might be able to use ansi.fth to implement some of the words.
Please do. These activities are not on the propforth team's main path, we have to stick to priorities or we get lost.
Propforth ...when passing data between cogs via the shared dictionary. The sd_driver when loaded (including the SD cog buffer) leaves only 4 longs (maybe 6) free in the cog. Thats fine, but try passing data to the driver from another cog via the shared dictionary. there are other ways but they are messy.
Please try some of the other (not messy) ways of passing data. In the spirit of the prop, the SD cog is ONLY tasked with talking to the SD by design.
When the high speed data data streams/ logging demo comes out, it will be clearer how Sal implements this.
Can you post how you are using PropGCC to get these to run? I have tried these yet.
The fix is quite simple ...... So please ponder a smooth transistion = and don't get too fancy. Let Leo Brodie do the teaching.
I nomimate Loopy to lead this effort. Loopy feels strongly, and has a plan. He is an experience teacher, and sees the issue from the perspective of the new user.
Loopsy is also in a position to benefit from the practice of implementing the words. The rest of us can help refine the definitions you produce, and help test them.
Loopy, you have write access to the propforth google code site, please consider this invitation to do as you suggest. WE (me at least) will help in any ways we can.
Seems to me a delta set of definitions would work well here. Leave the Forths on their current path, but provide the ANSI definitions separately for those wanting to work through "Starting Forth"
The only real instruction then being precisely how to incorporate them prior to working with the book.
Beware newcomers,Prof. Braino will hand vast amounts of work to you if you offer the slightest encouragement.
OMG, I am not sure I should be nominated for anything. Each of the three Forth developers have better oversight and knowledge as to what needs to be done AND how they wish to emphasize their systems.
This - a delta set of definitions - is a perfectly good alternative. But some may have something else in mind and not want to manage a fork to their own work that is just for study.
The plan then would be. And everyone merely has to be consistent in explaining it to newcomers.
A. Study "Starting Forth" with a completely compliant to "Starting Forth" version of Forth independent of the Propeller or on the Propeller if that is supported. If you have a prior knowledge and are able to use Forth, review the Starting Forth Lexicon to be sure you are currently up to speed. It will quickly show which chapters might need to be reviewed.
B. Study and review "Starting Forth" with an introduction and highlight to how the Propeller changes the basic approach as presented in "Starting Forth" in terms of your version of Forth (pfth, PropForth, TachyonForth, etc.)
C. Present the most significant Forth on Propeller features that are not included in the above for your version - e.g.; control of individual i/o pins; multiple cogs running at the same time; special words for 'bit-banging' slave devices; how the console can only talk to one Cog at a time and needs to be shifted around.
These are what the 'new learner' needs to know to get involved AND to be empowered to explore and develop on one's own.
This is a bit clearer than what I had in mind yesterday, and has a clear path for self-study.
There are lots of other things I'd personally like to know, but they are not important to developing an easy entry into Forth on the Propeller.
BTW, my main desktop is back in operation. I just unplugged the power mains and let it rest for a few days. There was something wrong. Whatever it is might return. But for now it seems not to be a serious damaging kind of failure - maybe I need a new power supply or a component is a intermittent power hog (the Nvidia card or the 1Tbyte are suspected). I just keep wondering why only the USB +5 was shut down and only after I selected which OS to use from Grub. (Maybe I should look in the GRUB2 software for a glitch).
@prof
Don't talk about it. Post YOUR code for all to see. Then we will have something to discuss.
@David I have dug up the C source for FIRST, but I have not got a clue as to how to compile it under GCC. Makes no sense to me.
I can do the THIRD code OK.
I nomimate Loopy to lead this effort. Loopy feels strongly, and has a plan. He is an experience teacher, and sees the issue from the perspective of the new user.
Loopsy is also in a position to benefit from the practice of implementing the words. The rest of us can help refine the definitions you produce, and help test them.
Loopy, you have write access to the propforth google code site, please consider this invitation to do as you suggest. WE (me at least) will help in any ways we can.
This would be a great experiment!
I feel somewhat tarred and feathered. But I am open to helping if it is wanted. Meanwhile, I still am only on Chapter 8 or 9 of Starting Forth as all this and trying to figure out EEPROM and SDcard storage have been rather counter-productive (That is why the 'ignore Chapter 3 - it doesn't apply'.)
Prof " In the spirit of the prop, the SD cog is ONLY tasked with talking to the SD by design." What are you on ????
prop doesn't have interupts, we just dedicate a cog to handle aa task. for example we program on cog 6, but cog 7 is the serial cog and does all the communication work. this leaves cog 6 open to do what my application needs, rather then also handle serial. its my understanding that this is how sd driver work as well. i may be mistaken.
@Ron, can you post a link for the FIRST source code? I'd like to take a look at it, and I can probably figure out how to compile it under PropGCC. I started looking at what it would take to implement ANS Forth from a small set of words, but I didn't get very far with it. I grouped the words :, ;, +, -, pick, roll, here, allot, @, !, immediate and create at the beginning of the pfth dictionary and used forget to remove all of the words after that. I think a few more words could be added to make life easier, but as I said I didn't get very far with it.
@Loopy, I looked at the "Starting Forth" word list you posted, and there are only a small number of words that aren't part of the CORE and CORE EXT sets. -TRAILING and BLANK are from the string set, 2CONSTANT is a double word and BLK is from the block set. ?STACK, 2- and 2+ are non-standard words. I think all of these could be easily written in Forth except for BLK. I think you need BLK only if you need the other block words in Chapter 3.
@prof_braino, I think most of us view you as one of the the lead Forth developers on the Prop. The Forth community is a diverse group that ranges from people who are only interested in small time-critical pieces of code to people who are interested in developing large and portable Forth applications. We should keep an open mind about the full range of Forth interests. I'm a C programmer, and 4 weeks ago I didn't really consider Forth to be a serious programming language. I now have a much better understanding of Forth, and I can see applications where it works well. However, when an experienced Forth programmer expresses negative views about certain aspects of Forth it makes me wonder about the usefullness of Forth.
Hi David
goto http://www.ioccc.org/
Now click on winners in the heading.
Select year 1992 and scan through untill you find Buzzard.
All the code is there and full Doc's
@Loopy, I looked at the "Starting Forth" word list you posted, and there are only a small number of words that aren't part of the CORE and CORE EXT sets. -TRAILING and BLANK are from the string set, 2CONSTANT is a double word and BLK is from the block set. ?STACK, 2- and 2+ are non-standard words. I think all of these could be easily written in Forth except for BLK. I think you need BLK only if you need the other block words in Chapter 3.
BLK
I have to look that up. I may have mistyped something. Ah ha! BLK is in Chapter Nine and I have not really gotten into using it.
I have taken a quick look at BLK in the Chapter Nine tutorial and it seems to be yet another good one to ask the new user to ignore, but I am not 100% sure of that. I have no trouble with understanding Chapter 3 as I just use GForth that supports just about the whole of "Starting Forth".
I'd say don't worry about it for now. THE MAIN OBJECTIVE is to have a precise inventory of what is and what is not included. If the learner feels he must learn all and everything in "Starting Forth", the learner can do it easily on another platform. The END GAME is to provide a good reasoning for what is not available rather than just making quips about "When you have seen one Forth, you have seen just one Forth" or saying "The Forth philosophy is...... Grasshopper" or "Just trust me, you don't need to know all that cr*p"
In other words, good teaching is about letting the learner know what's what, not about controlling what they learn.
@prof_braino, I think most of us view you as one of the the lead Forth developers on the Prop.
However, when an experienced Forth programmer expresses negative views about certain aspects of Forth it makes me wonder about the usefullness of Forth.
thanks, but i'm not. Sal is, i just help with docs and testing.
i dont follow on "negative views"?
maybe i'm not clear when i stress differentiating between the ANS standard (made by commitee, third hand)
, and forth designed by Moore.
maybe this will help: please look at DB05. polyFORTH reference manual.
this is the doc for forth, or at least as close as we can come without interviewing mr moore.
you may notice it adds forth 83 compatibility words, but warns not to use then, eg pick and roll are just a sign of incorrect usage.
also notive that polyFORTH targets the PC or workstation. if we target a microcontroller we use cross compiler, and those generally have a different word set.
all this is fine, im just trying to point out the differencr beteen the standard and a kernel for an application.
if the application is a general word set so we can use any forth and the brodie book to learn, that is a good idea and is doable.
then the test would something like "can the same code be run on pfth and propforth+ans extensions, and yield identical result". that would be really cool.
In other words, good teaching is about letting the learner know what's what, not about controlling what they learn.
You, sir have been away from the American Public Education System for too long. Good teaching is to prepare your students for the standardized testing so your school district can rank higher in the state rankings. A secondary function is to make sure the little leave school with the proper ideology and mindset. Tools for investigative learning, experiential learning, synthesis of ideas and questioning the world have fallen off the list of goals in most places.
I personally think "if you've seen one Forth, you've seen one Forth" is a classic! :0)
Yes. That is exactly what I was thinking. IMHO, that would be one heck of a crutch, but it would also make Forth more accessable to more people as well. My only concern would be the potential for a LOT of bad habits, not using the stack as intended / better cases.
Re: Learning
I've an academic interest too. Forth runs on older / smaller / diverse hardware. It's been very interesting to run Forths on retro-computers. They vary considerably though! Fig-Forth on Apple 2, for example. It does most things, but has words to directly manipulate the dictionary memory pointer... doesn't seem to know what a "cell" is, but the Forth basics all work well. I almost got to the point where I could just define "cell" for more exercises to work. That's cool honestly.
It's not as verbose as the Brody text, but it steps through a lot of core ideas. I found entering each one, then flexing it some with my own intentions worked well. I picked up a nice working set of the language over the weekend using both the old Apple and the Propeller, each running in a window. (Apple emulated for that purpose, but the real deal worked just fine, if a bit more slowly.)
The Apple has the blocks, screens and editor mode mentioned in Chapter three. Honestly, that's why I fired up the older Apple. That's how it used to get done. Words like "LIST" "LOAD" all made sense, once I saw the screens and blocks. Helpful, if very dated. What I found was the core Forth, a basic "needs to build the rest and just work" set is the default dictionary. One then loads in other goodies as needed, which are compiled right then. If it's good, copy the whole environment, do a save forth however that's done, and now you've got the working environment for that project. Another one may be entirely different!
maybe i'm not clear when i stress differentiating between the ANS standard (made by commitee, third hand)
, and forth designed by Moore.
The "negative views" are in reference to your stated opinions on ANS Forth, or any version of Forth that doesn't match PropForth. So what standard does PropForth implement? Is it Forth 83? Is there a specific document written by Moore that is used as the reference?
Hi David
goto http://www.ioccc.org/
Now click on winners in the heading.
Select year 1992 and scan through untill you find Buzzard.
I was able to compile FIRST using GCC under cygwin, and it ran without any modifications. It did generate a few warnings, but I was able to run all the demo programs.
I tried to run it on the Prop, but the program will require some modifications since it uses the standard input for the source. It shouldn't be too hard to get it to run. I'll post the code if I get it running.
The "negative views" are in reference to your stated opinions on ANS Forth, or any version of Forth that doesn't match PropForth. So what standard does PropForth implement? Is it Forth 83? Is there a specific document written by Moore that is used as the reference?
sorry dave. i am not communicating the point. my opinion is of the ANS standard itself, not of any forth in particular. sorry if you got that impression. like natural languages, forth is determined by its users, not by some book.
if the case of forth, the standard was written after the fact and added stuff to which moore objected, (as misleading). forth was what moore needed, propforth is what sal needs, if you need ans fine.
compare polyforth (moore's version, turned into a product) to the standard, you might see something interesting
Prof "prop doesn't have interupts, we just dedicate a cog to handle aa task. for example we program on cog 6, but cog 7 is the serial cog and does all the communication work. this leaves cog 6 open to do what my application needs, "
Don't you think I know that ??? you could of course direct 7 to 3 (AKA 3 >con etc etc etc)
rather then also handle serial.
Did I mention Serial ???? in relation to the SD_driver. NO I did not. I mentioned exchanging data betwen cogs via the shared dictionary which SHOULD be rock solid. It's the only resonable way to process data too and from the SD_diver.
its my understanding that this is how sd driver work as well. i may be mistaken
Is this an attemp to explain the SD_driver. There is no explaination so don't know if you are mistaken or not.
@prof_braino, thanks for your explanation. I think I understand a little bit better. It appears that we have different views when it comes to computer languages. BTW, Forth is a computer language, and not a natural language. When I look at a computer language I value features such as ease of programming, efficiency in programming, development tools, code re-use and portability. It seems that Forth is weak in all these areas. Any strengths that Forth claims are also found in other languages.
Portability requires standards. If everybody programs in their own dialect of Forth you have no portability, except within your own dialect. Yes, you can write a few words, and modify a few things to convert from one dialect to another, but that is a hinderance to having portable code. That's why I value standards.
Personally, I have little interest in whether today's version of Forth resembles Moore's version. I am more interested in being able to efficiently program in a language that can run on a large range of processors without modification. From what I can tell ANS Forth is the most widely accepted Forth standard, which is why I have focused mostly on it.
@Loopy, here are a few of the words that you listed from "Starting Forth". I didn't implement the ?STACK word since pfth aborts immediately on stack underflows. Maybe other Forth interpreters provide the equivalent of the ?STACK word. I also didn't implement BLK since this requires some of the other block words.
How about all the forths focus on the WIZ820io module, how about Ray's Logic PTP2 board and touch screen etc, so many "things" that end users actually want to use and control but it seems all the time is spent being able to download some ANS version of "Dinning Philosophers" in some ANS new prop language, getting it to "compile and run" and the developers call it success. Making gadgets that help people is success. Tachyon has a great start on this effort at the bottom of this page: https://docs.google.com/document/pub?id=1bEH0DfGmu99M1SqCbmlzl991Ssv2J5m6XWmkJX0XSl8
Go ahead, flame on, I'm working on equipment so small organic farmers can feed all those who can't / won't be able to feed themselves without having to eat roundup et al.
I have great respect for all of you who have spent consideral time and effort to gain mastery of your fields, just all the "standards" wars drive me nuts. If we all followed "the standards" Chip would never have created the Prop and we would all still be stuck in interrupt hell.
It has been interesting learning the internal workings of Forth, but I don't see much point in continuing work on an ANS Forth interpreter. It appears that Forth developers have little interest in standards and portability. I'll clean up a few more things in pfth, and post a final version in a day or two.
Comments
Personally, I think there is a lot of value in supporting the words used in "Starting Forth". I learned Forth by following the exercises in "Starting Forth", and I think it is an excellent approach.
The only real instruction then being precisely how to incorporate them prior to working with the book.
Then map each definition to a block on the SD. With a jump table, load the block for each word, as its called, on the fly.
Then leave the result on the stack, and forget the definition loaded from the block.
So it wouldn't' cost any dictionary space, aside from the jump table.
And it would execute almost as fast as a regular dictionary definition. The speed of the SD is about what the prop can handle.
So its doable, does any one want to give it a whirl? If it works, the same could done for Tachyon. But there's a whole bunch of words we're talking here.
I got a chance to build pForth yesterday and had a a play. I for one am all in favour of an ANS Forth. However Forth is only worth doing if it can take advantage of the unique architecture of the Prop Chip. Speed is not an issue (for me) if inline PASM can be included in a Forth word. It may be time for a re-think now you have the single version up and running. I really do hope you stick with it. Well done.
Tachyon and JDForth, are implementations that target the special requirements of the authors.
Propforth is is supposedly a general purpose Forth for the Prop. but it is not as robust as it is cracked up to be. It is fragile at best when passing data between cogs via the shared dictionary. The sd_driver when loaded (including the SD cog buffer) leaves only 4 longs (maybe 6) free in the cog. Thats fine, but try passing data to the driver from another cog via the shared dictionary. there are other ways but they are messy. The SDFS is really limited to running a few scripts. IMHO
There are tried and tested robust forth compliers out there, Portable Forth, pForth, being just one.
I have found a use for PropGCC at last.
LOL
Ron
My experience with getting started as a beginner in Forth has been a bit of a train wreck this past week. While a lot of well-intentioned and knowledgible people have tried to contribute, there are some very simple and clear facts.
First of all, ANS Forth 94 is not so much an issue as the lexicon of 'Starting Forth'. The beginner needs ALL the "Starting Forth" words to be supported (not all of ANS Forth 94) to acquire enough knowledge to build off of. If anyone chooses to leave them out of their own personal version of Forth, that version is rather useless to new learners.
The new learner can work with GForth, a demo of SwiftForth, or a lot of other Forths; but it seems rather foolish to send them over to another version when they expressed interest in learn it on the Propeller and in your particular version.
The situation is really rather odd and interesting. Many of the most adept users learned Forth decades ago. And like any natural language, the user has evolved and no longer desires to use less expressive ways to communicate that they had to use to acquire the language.
But, there is really only one text for new learners. It is 'Starting Forth' by Leo Brodie. People think that they can skip this text and merely teach the user on their own. A lot gets omitted. Or the learner is learning something else that really isn't as empowering as the original.
I have suggested that we exclude Chapter Three as it is all about storage that is not currently supported in Forth on the Propeller. But I missed the fact that the parenthesis are presented in this chapter. They are quite important to documentation. So far, these -- "(" and ")" -- are the only additions to the list, but as I read and reread the text, I may have a better list with a few more additions.
What am I trying to do?
Simply I am trying to help everyone that has created a version of Forth on the Propeller to have a simple way for increasing its use and popularity. That means making sure the new user has an easy, simple, and clear path to getting started. Even users that have learned it and want to review can use "Starting Forth" and the "Starting Forth Lexicon" to identify what they need to bone up on.
I do know this all sounds a bit pedantic, but after many years of teaching I really do feel that this is the only way to go. Most of you are very busy enjoying computing at a high level and don't realize that a new learner sees just a wall of jargon and mumbo-jumbo. They need a clear pathway into the subject. For C, that still is Richie and Kernighan; for Forth, that is still Leo Brodie.
Yes, there are words like PAGE and U.R and TRUE and FALSE that don't seem to be important to you. But if you work through the text exercise by exercise and chapter by chapter, they make very clear what Forth is and can be. At times I also am finding SEE extremely valuable, but it is NOT on the list, so don't worry about it unless you want to.
You can continue to omit these words or use alternatives as you like. But you make it harder to get wide interest and support for your particular efforts.
Fortunately, "Starting Forth" does not include .S and so, PropForth can at least avoid issues over ST?. I am pretty sure people will understand that having case sensitive FORTH allows less bytes to be consumed in a tight memory budget.
But asking an adept Forth user in 2012 to teach a rank beginner without reference to a basic text is just never going to work. The results are brutal for everyone - both the mentor and the student. Polite beginners will just give up and go away; others that really want to learn and are tougher are going to behave pretty much as I have done in the past week. And that was not fun for any of us.
So keep it simple. Insert the modified Starting Forth lexicon or at the very least, make a comparative listing which points out what is missing and what is called something else. And if somebody wants to learn, refer them to "Starting Forth" with the firm suggestion that they have to learn ALL of it before you can really help them with more advanced topics.
In closing, ANS Forth 94 is a whole separate topic. Treat it as such.
AND to Dave,
I would eventually love to sit down with your early C code for pfth and read it to learn more about both languages - C and Forth. Even it that doesn't run fast on the Propeller, I suspect it runs fine on other platforms and it very informative to someone that wants to learn more than just Forth.
The fix is quite simple - just make a list of what should be used instead, with your own wise explainations. It may be that only pfth will ever fully complly with "Starting Forth" or it may be that none of the "Forth on the Propeller' varieties will be capablable of doing so.
Still, I personally have needed "Starting Forth" as an entry point. And I feel strongly that many others do too. So please ponder a smooth transistion = and don't get too fancy. Let Leo Brodie do the teaching.
Why... because they don't apply to the prop, in the eyes of the guy that doing all the work
Anyone is free to implement any words they want. The fact that nobody has noticed these missing up till now and decided these are worth implementing, is evidince that they are not needed, and not missed. You are correct, it is a mostly trivial effort to implement these words. I invite anyone to do so, I will at them to the "ANSII Compatibility" extension set, that I planned to do when all the high priority stuff is complete.
That is a valid choice, but we decided it is the incorrect choice for our purposes. You of course are free to define anything any way you want. But remember, the standard is the "yardstick" and not the object we are measuring; those words ! and @ are simply WRONG. These are only used when there is ONLY ONE POSSIBLE CELL SIZE. As on a byte address able ONLY machine.
Please do. These activities are not on the propforth team's main path, we have to stick to priorities or we get lost.
Please try some of the other (not messy) ways of passing data. In the spirit of the prop, the SD cog is ONLY tasked with talking to the SD by design.
When the high speed data data streams/ logging demo comes out, it will be clearer how Sal implements this.
Can you post how you are using PropGCC to get these to run? I have tried these yet.
I nomimate Loopy to lead this effort. Loopy feels strongly, and has a plan. He is an experience teacher, and sees the issue from the perspective of the new user.
Loopsy is also in a position to benefit from the practice of implementing the words. The rest of us can help refine the definitions you produce, and help test them.
Loopy, you have write access to the propforth google code site, please consider this invitation to do as you suggest. WE (me at least) will help in any ways we can.
This would be a great experiment!
Beware newcomers, Prof. Braino will hand vast amounts of work to you if you offer the slightest encouragement.
OMG, I am not sure I should be nominated for anything. Each of the three Forth developers have better oversight and knowledge as to what needs to be done AND how they wish to emphasize their systems.
This - a delta set of definitions - is a perfectly good alternative. But some may have something else in mind and not want to manage a fork to their own work that is just for study.
The plan then would be. And everyone merely has to be consistent in explaining it to newcomers.
A. Study "Starting Forth" with a completely compliant to "Starting Forth" version of Forth independent of the Propeller or on the Propeller if that is supported. If you have a prior knowledge and are able to use Forth, review the Starting Forth Lexicon to be sure you are currently up to speed. It will quickly show which chapters might need to be reviewed.
B. Study and review "Starting Forth" with an introduction and highlight to how the Propeller changes the basic approach as presented in "Starting Forth" in terms of your version of Forth (pfth, PropForth, TachyonForth, etc.)
C. Present the most significant Forth on Propeller features that are not included in the above for your version - e.g.; control of individual i/o pins; multiple cogs running at the same time; special words for 'bit-banging' slave devices; how the console can only talk to one Cog at a time and needs to be shifted around.
These are what the 'new learner' needs to know to get involved AND to be empowered to explore and develop on one's own.
This is a bit clearer than what I had in mind yesterday, and has a clear path for self-study.
There are lots of other things I'd personally like to know, but they are not important to developing an easy entry into Forth on the Propeller.
BTW, my main desktop is back in operation. I just unplugged the power mains and let it rest for a few days. There was something wrong. Whatever it is might return. But for now it seems not to be a serious damaging kind of failure - maybe I need a new power supply or a component is a intermittent power hog (the Nvidia card or the 1Tbyte are suspected). I just keep wondering why only the USB +5 was shut down and only after I selected which OS to use from Grub. (Maybe I should look in the GRUB2 software for a glitch).
Don't talk about it. Post YOUR code for all to see. Then we will have something to discuss.
@David I have dug up the C source for FIRST, but I have not got a clue as to how to compile it under GCC. Makes no sense to me.
I can do the THIRD code OK.
Ron
I feel somewhat tarred and feathered. But I am open to helping if it is wanted. Meanwhile, I still am only on Chapter 8 or 9 of Starting Forth as all this and trying to figure out EEPROM and SDcard storage have been rather counter-productive (That is why the 'ignore Chapter 3 - it doesn't apply'.)
prop doesn't have interupts, we just dedicate a cog to handle aa task. for example we program on cog 6, but cog 7 is the serial cog and does all the communication work. this leaves cog 6 open to do what my application needs, rather then also handle serial. its my understanding that this is how sd driver work as well. i may be mistaken.
@Loopy, I looked at the "Starting Forth" word list you posted, and there are only a small number of words that aren't part of the CORE and CORE EXT sets. -TRAILING and BLANK are from the string set, 2CONSTANT is a double word and BLK is from the block set. ?STACK, 2- and 2+ are non-standard words. I think all of these could be easily written in Forth except for BLK. I think you need BLK only if you need the other block words in Chapter 3.
@prof_braino, I think most of us view you as one of the the lead Forth developers on the Prop. The Forth community is a diverse group that ranges from people who are only interested in small time-critical pieces of code to people who are interested in developing large and portable Forth applications. We should keep an open mind about the full range of Forth interests. I'm a C programmer, and 4 weeks ago I didn't really consider Forth to be a serious programming language. I now have a much better understanding of Forth, and I can see applications where it works well. However, when an experienced Forth programmer expresses negative views about certain aspects of Forth it makes me wonder about the usefullness of Forth.
goto http://www.ioccc.org/
Now click on winners in the heading.
Select year 1992 and scan through untill you find Buzzard.
All the code is there and full Doc's
Its very small. Not a big job in PASM
Ron
Ron
BLK
I have to look that up. I may have mistyped something. Ah ha! BLK is in Chapter Nine and I have not really gotten into using it.
I have taken a quick look at BLK in the Chapter Nine tutorial and it seems to be yet another good one to ask the new user to ignore, but I am not 100% sure of that. I have no trouble with understanding Chapter 3 as I just use GForth that supports just about the whole of "Starting Forth".
I'd say don't worry about it for now. THE MAIN OBJECTIVE is to have a precise inventory of what is and what is not included. If the learner feels he must learn all and everything in "Starting Forth", the learner can do it easily on another platform. The END GAME is to provide a good reasoning for what is not available rather than just making quips about "When you have seen one Forth, you have seen just one Forth" or saying "The Forth philosophy is...... Grasshopper" or "Just trust me, you don't need to know all that cr*p"
In other words, good teaching is about letting the learner know what's what, not about controlling what they learn.
thanks, but i'm not. Sal is, i just help with docs and testing.
i dont follow on "negative views"?
maybe i'm not clear when i stress differentiating between the ANS standard (made by commitee, third hand)
, and forth designed by Moore.
maybe this will help: please look at DB05. polyFORTH reference manual.
this is the doc for forth, or at least as close as we can come without interviewing mr moore.
you may notice it adds forth 83 compatibility words, but warns not to use then, eg pick and roll are just a sign of incorrect usage.
also notive that polyFORTH targets the PC or workstation. if we target a microcontroller we use cross compiler, and those generally have a different word set.
all this is fine, im just trying to point out the differencr beteen the standard and a kernel for an application.
if the application is a general word set so we can use any forth and the brodie book to learn, that is a good idea and is doable.
then the test would something like "can the same code be run on pfth and propforth+ans extensions, and yield identical result". that would be really cool.
You, sir have been away from the American Public Education System for too long. Good teaching is to prepare your students for the standardized testing so your school district can rank higher in the state rankings. A secondary function is to make sure the little leave school with the proper ideology and mindset. Tools for investigative learning, experiential learning, synthesis of ideas and questioning the world have fallen off the list of goals in most places.
I personally think "if you've seen one Forth, you've seen one Forth" is a classic! :0)
Yes. That is exactly what I was thinking. IMHO, that would be one heck of a crutch, but it would also make Forth more accessable to more people as well. My only concern would be the potential for a LOT of bad habits, not using the stack as intended / better cases.
Re: Learning
I've an academic interest too. Forth runs on older / smaller / diverse hardware. It's been very interesting to run Forths on retro-computers. They vary considerably though! Fig-Forth on Apple 2, for example. It does most things, but has words to directly manipulate the dictionary memory pointer... doesn't seem to know what a "cell" is, but the Forth basics all work well. I almost got to the point where I could just define "cell" for more exercises to work. That's cool honestly.
I found this primer fun to work through: http://ficl.sourceforge.net/pdf/Forth_Primer.pdf
It's not as verbose as the Brody text, but it steps through a lot of core ideas. I found entering each one, then flexing it some with my own intentions worked well. I picked up a nice working set of the language over the weekend using both the old Apple and the Propeller, each running in a window. (Apple emulated for that purpose, but the real deal worked just fine, if a bit more slowly.)
The Apple has the blocks, screens and editor mode mentioned in Chapter three. Honestly, that's why I fired up the older Apple. That's how it used to get done. Words like "LIST" "LOAD" all made sense, once I saw the screens and blocks. Helpful, if very dated. What I found was the core Forth, a basic "needs to build the rest and just work" set is the default dictionary. One then loads in other goodies as needed, which are compiled right then. If it's good, copy the whole environment, do a save forth however that's done, and now you've got the working environment for that project. Another one may be entirely different!
I tried to run it on the Prop, but the program will require some modifications since it uses the standard input for the source. It shouldn't be too hard to get it to run. I'll post the code if I get it running.
sorry dave. i am not communicating the point. my opinion is of the ANS standard itself, not of any forth in particular. sorry if you got that impression. like natural languages, forth is determined by its users, not by some book.
if the case of forth, the standard was written after the fact and added stuff to which moore objected, (as misleading). forth was what moore needed, propforth is what sal needs, if you need ans fine.
compare polyforth (moore's version, turned into a product) to the standard, you might see something interesting
Don't you think I know that ??? you could of course direct 7 to 3 (AKA 3 >con etc etc etc)
rather then also handle serial.
Did I mention Serial ???? in relation to the SD_driver. NO I did not. I mentioned exchanging data betwen cogs via the shared dictionary which SHOULD be rock solid. It's the only resonable way to process data too and from the SD_diver.
its my understanding that this is how sd driver work as well. i may be mistaken
Is this an attemp to explain the SD_driver. There is no explaination so don't know if you are mistaken or not.
BTW This is David's Thread
Ron
Portability requires standards. If everybody programs in their own dialect of Forth you have no portability, except within your own dialect. Yes, you can write a few words, and modify a few things to convert from one dialect to another, but that is a hinderance to having portable code. That's why I value standards.
Personally, I have little interest in whether today's version of Forth resembles Moore's version. I am more interested in being able to efficiently program in a language that can run on a large range of processors without modification. From what I can tell ANS Forth is the most widely accepted Forth standard, which is why I have focused mostly on it.
Go ahead, flame on, I'm working on equipment so small organic farmers can feed all those who can't / won't be able to feed themselves without having to eat roundup et al.
I have great respect for all of you who have spent consideral time and effort to gain mastery of your fields, just all the "standards" wars drive me nuts. If we all followed "the standards" Chip would never have created the Prop and we would all still be stuck in interrupt hell.