The attached may help some learners study PropForth. This is olny a by-product of what is evolving into creation of better presentation of the material about PropForth in general.
I pretty much am learning by editting. If these things benefit all, it is all to the good.
Good point about Forth Inc. and microcontrollers and ANS Forth...... but the Propeller is a bit non-standard for even the micro-controller world and a lot of assumpts about the ANS Forth 94 standard never anticipated such and architecture.
Nonetheless, I am all for NOT having to relearn vocabulary for the sake of novelty. Still, a standard remains until a new one is required (unless its purpose is to create a barrier to change and innovation). I keep saying this. I consider ANS Forth 94 a starting point for new learners of today, not much more.
This is a good thing, you don't give up. Nobody has even done this effort, between Brodies book and now there have only been MORE complicated explanations, since forth is generally used by electronics engineers that don't want to bother with software. Making an easier explanation has been my goal for a couple years now.
I have been trying to find an easy way in to PropForth. .
Like most worhtwhile things in this life, the easiest way is to practice every day for three years to get started, then for another 5 years to get good.
Your PropForth.html shows an incredible amount of hard work, .
This one is Sal's that's why its noticably better than the wiki pages.
I came back to the PropForth.html as the ONLY reliable and complete source document for PropForth Lexicon. .
I should have mentioned this sooner.
Still, I and other beginners need something that was shorter to work with,
IF you could please ask specific questions, as they come up, we could try to get specific answers in the sequence you need them. This almost worked with caskaz, but he jumped too far ahead of me and I can't keep up with his new hardware, etc. But is you concentrate on the materials, we might make a controlled progress.
I would suggest simple "one item driver" type experiments: blink the LED, print some text, turn the stepper, move the servo, put them together in a project, etc.
Well.... is everyone ready for yet another Loopy bombshell?
I will have a cosmetic and stylistic enhancement of the PropForth.htm completed a bit later tonight.
I did NOT get into rewriting text. But I did make it visually easier to see what is going on and where you are going. I am taking a bit of a risk here as youall may feel that I am doing something a bit radical. But I think is will be very, very good for new users (and old) to navigate and enjoy.
Thanks, the catagorization is coming, but I am working on getting a finer grain with sub-categories as well.
The PropForth Quick Reference is useful, but obiviously out-dated by V5.03 as it was for V4.5 and there are few fuzzy areas in it.
Meanwhile here is a bit of a preliminary view of the PropForth.htm revised for readablity. Please be advised that I do know that their are images in the Logic Analyser that did not transfer to the PDF version. And I am going to hold back the HTML version for a day or two to be sure that something dreadful did not creep in with all my fiddling around (these things always happen, don't they? I already see a wrong color for the Chapter 7 heading. grrr....)
So far, I think I caught all my big boo-boos. This is large. I can post HTML on the Forum, but at least this was permitted.
@EVERYONE ==> This document is the reason I really like learning PropForth - very, very cool!
I think the categories are needed and also one of the harder things to get right. There are obviously beginner, intermediate and advanced words in some of the categories. For example, >con is an early word you will want to use as soon as you start realizing there are potentially 6 other Forth engines to use just waiting for you. The IO channel words and dictionary words may take a while to get to and delve into the internals of the Forth interpreter more than some people may want to go.
If size becomes an issue on the forum, don't forget, you can always post this as a working document to the wiki and link to it from the forum threads.
Keep up the good work, your progress is far more impressive than my intentions!
Yes, getting categories right is a bit tricky. So I am taking a bit of time to think about.
Beginner, intermediate, and advanced is another matrix -- not functionality. That might be done in another document or as an overlay.... afterwards.
Getting the functionality right comes first. Of course some of the words seem to straddle between two worlds and that has been rather annoying. It is all about semantics and point of view. I am working on it - one latte at a time.
But I now know that CORE and NON-CORE are rather silly to the learner and most users. Mostly I am thinking in terms a programer wants to group. Bit manipulation, numerical base. Pin I/O, a standard i/o console, and so on.
bear in mind that the OTHER part is the projects. the words donnt matter much without using it to implement say a servo spider from 18 individual servos, or the POV demo from a hacksaw blade, 7 LEDs and door bell solenoid. the demo makes it come to life in a way that just the text does not quite achive.
after loopy gets the docs going we might whip up some junk-box demos?
Anybody every consider Forth programed SumoBots. They might be very handy to be able to alter behavior for each round and different opponets. Unlike other code that takes a lot to edit-compile-load, one just calls ups a few words and tweaks.
And then there are line following and matrix competitions that might benefit as well.
Right now, I am very deep into a revision of the PropForth.htm for easier reading and a clean up of general language errors. This will make it that much easier for the new user to enjoy learning PropForth.
But I am not changing the style or content. Sal Sanci wrote quite well and the examples are very clear and concise. One just has to get used to his approach of starting every example with 'cs' for clear the stack and then putting the whole example on one line.
I had previously thought Forth was about entering two or three words and hitting return, but when you really understand it - the lines become phrases that are longer. There are lots and lots of example to help you see what does what.
On my list of a bazillion things to do is try and put one of my S2 under PropForth control. My Sumobots obviously need a brain transplant but once that happens, PropForth would be a worthy control platform. Add bluetooth and you could even tweak them remotely....which of course is completely illegal in competition! While my imagination is my friend, time is my enemy - at least I should never run out of things to do!
It's like telling a story where you need to build your details up from the bottom. I'm still in the clicking stage but once things click, it's fun to look at the word definitions and see how they are put together and how well they tell their story. While Peter's and Sal's styles are different, I think they both really write some elegant and easily readable code.
BTW, I am still working on getting the 'Starting Forth Lexicon' compared to the 'PropForth V5.03 lexicon'
Delays and distractions crept it, but the good news is that I now understand that the PropForth.htm is the foremost listing - don't bother with printing out Words listings as they may be varied and incomplete.
Someone is providing the comprehensiove picture -- in documentation. I guess it is all Sal Sanci's.
this is actually one of the competitions offered by Chibots.org, the local robot club.
the Little Robot project is designed to allow more folks to partipate.
the little robot can be programmed for robot sumo, this is for the next phase of the demo.
Okay, this is just to expedite anyone that started with "Starting Forth Lexicon" and is migrating to PropForth 5.0.
It is a list of missing or changed items from the "Starting Forth Lexicon" and it doesn't have all the additional PropForth lexicon that you will eventuallly acquire.
Loopy, that's quite a list of words you would have to implement in PropForth to be able to use it with Starting Forth. I'm working on a PASM version of pfth that supports all of the ANS core words. The interpreter supports about 50 words, and the remaining ANS words are implemented in a Forth program. The Forth program could be ported to PropForth to provide ANS support. I hope to post it in a day or two.
I revised it with something much better. I can download it or my brower is fooling me. Maybe it is only available in Taiwan.
This version just may lead to some very intelligent discussion about ANS Forth 94 versus PropForth adaptations.
a couple corrections:
c! and c@ are listed as none, maybe these should be listed as renamed C! and C@. Also see W! W@ L@ L!, and COG ! COG@
The words not implemented are ! and @ since cell size is ambiguous
double word support is listed as "not needed", should be "not implemented in kernel"
file and os stuff is listed as "use saveforth" should be "use file system kernels EEPROM or SD"
instead of mod pf has /mod and */mod
there is "leave" on the propforth dictionary
Instead of u.r in propforth there is u. because Sal like to save on r's
tib is not used, but the space 10 bytes(?) after "here" is uses as scratch area (This might have changed recently, I need to check)
create ...Does> is is not used in propforth, we use separate compile time words and run time words.
sp@ and sp0 - there is something in propforth for directly accessing stack elements, but I can't find it at the moment.
That's all I got right now, this is a a very good start.
After the words are identified that are needed to be ANSII or Starting Forth compatible, it is a straight forward exercise to implement the words. Loopy is off to a good start.
Concerning @ ! the memory access words: These are usually based on the cell size and date from ancient times when the entire processor was either byte addressable or word addressable, and there was a single memory space. On modern processors, we can address bytes (characters), words, longs, and sometimes double, so this ! and @ alone are no longer adequate. On the prop, the default word size is word in the hub, and long in the cogs, so neither cell size is suitable as default (and so we explicitly define C! C@, W@ W!, L@ L!, COG! COG@ so there would be no confusion). BUT for the purposes of compatibility with "Starting Forth" examples, we could select either word our long, and work in hub or cog space, and be code compatible with the examples. Since the examples are short, and mostly not complete applications, this might work.
c! and c@ are listed as none, maybe these should be listed as renamed C! and C@. Also see W! W@ L@ L!, and COG ! COG@
The words not implemented are ! and @ since cell size is ambiguous
double word support is listed as "not needed", should be "not implemented in kernel"
file and os stuff is listed as "use saveforth" should be "use file system kernels EEPROM or SD"
instead of mod pf has /mod and */mod
there is "leave" on the propforth dictionary
Instead of u.r in propforth there is u. because Sal like to save on r's!
tib is not used, but the space 10 bytes(?) after "here" is uses as scratch area (This might have changed recently, I need to check)
create ...Does> is is not used in propforth, we use separate compile time words and run time words.
sp@ and sp0 - there is something in propforth for directly accessing stack elements, but I can't find it at the moment.
That's all I got right now, this is a a very good start.
OKAY!!!!!!!!!! Finally some good input about specifics rather than a generalized debate about it is not ANS Forth 94 and it is just the way Sal wants it.
c! and c@ versus C! and C@ --- They are indeed the same. It seems I forgot that I shifted all the Starting Forth lexicon from upper case to lower case for automated comparison.
PropForth created the spread of C!, W!, L!, COG!, C@,W@,L@, and COG@ for some reason. Rather than having a cell that is the minimum 16bit size as ANS Forth 94 did, the stack is now 32bit and the cell size is a bit fuzzy. It can be 32bit or 16bit, maybe even 8 bit --- but the Dictionary is certainly not 32bit or 8 bit --- it is 16 bit to add more space and to optimize speed. Why would anyone bother with 16 maths when 32 bit is available?
So a lot of confusion. "Starting Forth describes C! and C@ as store and retrive characters and that does imply a conversion form ASCII to letters - but it may just happen in the dumb terminal. C! and C@ are simply 8 bits.
Double word "not needed" versus double word "not implemented" -- The debate is merely point of view. Is there really a need for 64 bit maths on the Propeller. If I were to desire 64 bit maths, I'd use my Intel Quad 64bit at 2.4Ghz rather than a 32bit Propeller.
Mod versus whatever PropForth does -- Are you saying the same features are just provided in a different way? What does the learner have to relearn and adapt? If you change it, defend the change and teach it to new students. Maybe the ANS Forth 94 way was adequate.
"Sal likes to save the 'r's'" and he also avoids the leading ? or stand alone ? at all costs. That's interesting..... personal flourishes? But Sal simply ignores the fact that formatting number as right justified is a useful tool and needed for presentation.
Dig deep and consider how and why Leo Brodie taught 'Starting Forth' his way; and then consider that you might have to present a contrasting scheme in a similar 12 chapters to adequatly match the ground he covered.
Regarding "leave"... I somehow missed it. It seems that "abort" and "abort?" also exist, but are not listed in the PropForth.htm in Section 9. I may be wrong. But this kind of items might be my error or your omission from documents.
In closing. I am very happy as I am finally making some real headway. There has been a remarkable amount of resistance to investigating different approaches to Forth in detail.
And please, don't tell me again that PropForth doesn't use "Create ... Does>" without telling me what the replacement is. Is this a secret? What is that separate compile time methodology? Is it none of my business?
@Prof Braino.
The short story.... I have investigated further, thought about your input. And so... here is another revision. Working towards a perfect V1.0.
Why would anyone bother with 16 maths when 32 bit is available?
In the old days, we used 16 bit when it is sufficient, and we use 32 bit when we needs it. Now we use 32 bit when id does the job (pretty much everyday) and use 64 or 128 bit when we need it (for calulating course correction on the probe to jupiter, which is a little further down the "to-do" list)
[/QUOTE]So a lot of confusion. "Starting Forth describes C! and C@ as store and retrive characters and that does imply a conversion form ASCII to letters - but it may just happen in the dumb terminal. C! and C@ are simply 8 bits.[/QUOTE]
eliminate the confusion. byte = character. We didn't use "B" for byte because some folks want "B" for bit, we already had that discussion in the '80's (what a pain some folks are). BYTE is 8 bits, character is the old name, we C because character used to be 8 bits.
Double word "not needed" versus double word "not implemented" -- The debate is merely point of view. Is there really a need for 64 bit maths on the Propeller. If I were to desire 64 bit maths, I'd use my Intel Quad 64bit at 2.4Ghz rather than a 32bit Propeller.
When you need it, you need it. If you want it, it there with the addition of a simple extension. There need be no debate.
Mod versus whatever PropForth does -- Are you saying the same features are just provided in a different way? What does the learner have to relearn and adapt? If you change it, defend the change and teach it to new students. Maybe the ANS Forth 94 way was adequate.
I only look are weird math when I need to use it. We should look at the goes-inta's and the comes-outta's for each definition, and figure where they differ. Then look at the PASM words that can implement each function, we should find that the words implemented were the smallest, most efficient way that they could be done on the prop, and the awkward implementations were skipped.
"Sal likes to save the 'r's'" and he also avoids the leading ? or stand alone ? at all costs. That's interesting..... personal flourishes? But Sal simply ignores the fact that formatting number as right justified is a useful tool and needed for presentation.
OK, I saw being a smart @$$. I'm not good at humor. Sal wanted the leave off the R in u.r since it makes no sense to him, and apparently there was a big discussion about this when writing the standard, and the wrong side had the loudest voice. Or something, maybe I just made that up. In anycase, Sal used u. instead of u.r we may redefine this in a single definition if we wish. What does ? do anyway? I never use it, apearently Sal never does either, or it woul be in there. Just write one, it takes 2 seconds.
Dig deep and consider how and why Leo Brodie taught 'Starting Forth' his way; and then consider that you might have to present a contrasting scheme in a similar 12 chapters to adequatly match the ground he covered.
The world was 16 bit. polyFORTH was the best forth in the world, and there was no standard. People had recently moved out of caves but still worked in silos. Now we have the prop.
It seems that "abort" and "abort?" also exist, but are not listed in the PropForth.htm in Section 9.
I also thought the abort words were present, but maybe Sal saw these as sloppy or unused, or maybe he just forgot them. Please open an issue to put these in, Sal will dig them out or at least tell us what the deal is.
And please, don't tell me again that PropForth doesn't use "Create ... Does>" without telling me what the replacement is. Is this a secret? What is that separate compile time methodology? Is it none of my business?
Propforth omits CREATE. DOES> because the dictionary doesn't work that way, AND we prefer separate compile time words and separate run time words. Experts that wish to use CREATE ... DOES> are capable of implementing them. Those not capable of implementing them likely should not use them in the first place, in any case they will just have to wait until the they or somebody else goes to all the trouble (that is really not worth it, but you won't know till you try).
Similar are the return stack words R@ >R R>. These are totally dangerous and you WILL use them wrong the first dozen times or so, but they are needed in creating the dictionary entries so they are included. When things go wonky, its mostly due to in correct return stack word use, incorrect compiletime/runtime behavor word use, or other. We've eliminated the first two biggies, so now we just have to worry about the rest.
One more thing - we're getting beyond my area, particularly with dictionary implementation, kernel structure, and differences from DPANS94. You might want to get in touch with Nick Lordi (nglordi), he has much more experience and knowledge than me on all things forth.
Propforth omits CREATE. DOES> because the dictionary doesn't work that way, AND we prefer separate compile time words and separate run time words. Experts that wish to use CREATE ... DOES> are capable of implementing them. Those not capable of implementing them likely should not use them in the first place, in any case they will just have to wait until the they or somebody else goes to all the trouble (that is really not worth it, but you won't know till you try).
I want to define a large number of words with the same kind of action.
Which is formating the name of the word plus a number of stack items to a string and sending this to a serial port.
From the 'learning forth - and the chapter about CREATE ... DOES> and the DEFINING WORDS, my impression was,
that the most effective way for doing this would be to define a new DEFINING WORD 'DefCmd'.
kind of 'DefCmd CMDname' which will generate a new word CMDname ( n1 n2 n3 n4 -- )
Similar to the example of defining the CONSTANT and VARIABLE DEFINING WORDS.
so how would this be done then? in PropForth / or in Tachyon ( where I will need it )
or what would be the 'workaround' doing this with separate compiletime an runtime words?
I want to define a large number of words with the same kind of action.
Which is formating the name of the word plus a number of stack items to a string and sending this to a serial port.
From the 'learning forth - and the chapter about CREATE ... DOES> and the DEFINING WORDS, my impression was,
that the most effective way for doing this would be to define a new DEFINING WORD 'DefCmd'.
kind of 'DefCmd CMDname' which will generate a new word CMDname ( n1 n2 n3 n4 -- )
Similar to the example of defining the CONSTANT and VARIABLE DEFINING WORDS.
so how would this be done then? in PropForth / or in Tachyon ( where I will need it )
or what would be the 'workaround' doing this with separate compiletime an runtime words?
In propforth, you could look at the code and see how Sal does, and do that. You might have a couple questions, because nobody has asked about till now, and we therefore didn't do that part of the docs (we only do what we guess is needed, and ad as specific questions are asked).
Otherwise, you could look at DPANS94 and see what those words do, and write your own create and does> words to d the same. This is what most folks do on any forth.
If you have trouble, (after you try) just ask here, and we'll try to help you alone. (Me, I have a day job ad they don't let me do non work stuff besides email, so my time is limited).
I am trying to just accept that the CREATE ... DOES> is not a part of PropForth or Tachyon. And I do understand that this is getting rather deep into Forth. But it is at the heart of providing an 'extensible compiler' and that was thought to be a significant Forth feature in the past.
So, I guess one can make these words themselves, or use other words to do the same thing. Dave Hein mentioned that there was a requirement for a flag to properly have at least one of these words work, and that not providing that flag was part of the reason for their omission.
The comment that CREATE ... DOES> does not exist because 'the dictionary doesn't work that way' seems to indicate that a) these versions are not extensible compiler capable and b) to achieve that goal would require using the kind of dictionary that Dave Hein has been using.
I am really hoping that there is another alternative that I am just missing and that it is just a case of creating some words.
So I am really wondering if this is a relatively minor task of creating a few words, or if it would require a major rebuilding of the dictionary's internal workings. I've not really idea, but I can certain understand why MJB would desire such a feature.
We only have one of the [ and ] words, the ] and that is a bit disconcerting as well.
Comments
I pretty much am learning by editting. If these things benefit all, it is all to the good.
Good point about Forth Inc. and microcontrollers and ANS Forth...... but the Propeller is a bit non-standard for even the micro-controller world and a lot of assumpts about the ANS Forth 94 standard never anticipated such and architecture.
Nonetheless, I am all for NOT having to relearn vocabulary for the sake of novelty. Still, a standard remains until a new one is required (unless its purpose is to create a barrier to change and innovation). I keep saying this. I consider ANS Forth 94 a starting point for new learners of today, not much more.
This is a good thing, you don't give up. Nobody has even done this effort, between Brodies book and now there have only been MORE complicated explanations, since forth is generally used by electronics engineers that don't want to bother with software. Making an easier explanation has been my goal for a couple years now.
Like most worhtwhile things in this life, the easiest way is to practice every day for three years to get started, then for another 5 years to get good.
This one is Sal's that's why its noticably better than the wiki pages.
I should have mentioned this sooner.
IF you could please ask specific questions, as they come up, we could try to get specific answers in the sequence you need them. This almost worked with caskaz, but he jumped too far ahead of me and I can't keep up with his new hardware, etc. But is you concentrate on the materials, we might make a controlled progress.
I would suggest simple "one item driver" type experiments: blink the LED, print some text, turn the stepper, move the servo, put them together in a project, etc.
I think I have never jumped too far ahead of you.
I merely like controlling hardware by PropForth.
You are like Obi-Wan.
? Stuck on a back world planet to watch the kids until the party gets started??
C = Blaster
Forth = Lightsaber
Sorry, the Forth is strong in this one!
I will have a cosmetic and stylistic enhancement of the PropForth.htm completed a bit later tonight.
I did NOT get into rewriting text. But I did make it visually easier to see what is going on and where you are going. I am taking a bit of a risk here as youall may feel that I am doing something a bit radical. But I think is will be very, very good for new users (and old) to navigate and enjoy.
ok i started to look at short lex. this is a big step forward.
the next step is to divide this list into about 7 catagories. math, branching, text i/o, stack, memory
a couple of these could be further divided, for example text i/o could consist of numbers, alpha strings, alphanumerics, formatted numbers, etc
it always helps me to organize the words into sets so i can find the one i need, and gives the individual words life and identity.
lunch is over, more when i get home....
The PropForth Quick Reference is useful, but obiviously out-dated by V5.03 as it was for V4.5 and there are few fuzzy areas in it.
Meanwhile here is a bit of a preliminary view of the PropForth.htm revised for readablity. Please be advised that I do know that their are images in the Logic Analyser that did not transfer to the PDF version. And I am going to hold back the HTML version for a day or two to be sure that something dreadful did not creep in with all my fiddling around (these things always happen, don't they? I already see a wrong color for the Chapter 7 heading. grrr....)
So far, I think I caught all my big boo-boos. This is large. I can post HTML on the Forum, but at least this was permitted.
@EVERYONE ==> This document is the reason I really like learning PropForth - very, very cool!
I think the categories are needed and also one of the harder things to get right. There are obviously beginner, intermediate and advanced words in some of the categories. For example, >con is an early word you will want to use as soon as you start realizing there are potentially 6 other Forth engines to use just waiting for you. The IO channel words and dictionary words may take a while to get to and delve into the internals of the Forth interpreter more than some people may want to go.
If size becomes an issue on the forum, don't forget, you can always post this as a working document to the wiki and link to it from the forum threads.
Keep up the good work, your progress is far more impressive than my intentions!
Beginner, intermediate, and advanced is another matrix -- not functionality. That might be done in another document or as an overlay.... afterwards.
Getting the functionality right comes first. Of course some of the words seem to straddle between two worlds and that has been rather annoying. It is all about semantics and point of view. I am working on it - one latte at a time.
But I now know that CORE and NON-CORE are rather silly to the learner and most users. Mostly I am thinking in terms a programer wants to group. Bit manipulation, numerical base. Pin I/O, a standard i/o console, and so on.
after loopy gets the docs going we might whip up some junk-box demos?
And then there are line following and matrix competitions that might benefit as well.
Right now, I am very deep into a revision of the PropForth.htm for easier reading and a clean up of general language errors. This will make it that much easier for the new user to enjoy learning PropForth.
But I am not changing the style or content. Sal Sanci wrote quite well and the examples are very clear and concise. One just has to get used to his approach of starting every example with 'cs' for clear the stack and then putting the whole example on one line.
I had previously thought Forth was about entering two or three words and hitting return, but when you really understand it - the lines become phrases that are longer. There are lots and lots of example to help you see what does what.
It's like telling a story where you need to build your details up from the bottom. I'm still in the clicking stage but once things click, it's fun to look at the word definitions and see how they are put together and how well they tell their story. While Peter's and Sal's styles are different, I think they both really write some elegant and easily readable code.
Delays and distractions crept it, but the good news is that I now understand that the PropForth.htm is the foremost listing - don't bother with printing out Words listings as they may be varied and incomplete.
Someone is providing the comprehensiove picture -- in documentation. I guess it is all Sal Sanci's.
this is actually one of the competitions offered by Chibots.org, the local robot club.
the Little Robot project is designed to allow more folks to partipate.
the little robot can be programmed for robot sumo, this is for the next phase of the demo.
It is a list of missing or changed items from the "Starting Forth Lexicon" and it doesn't have all the additional PropForth lexicon that you will eventuallly acquire.
Quick Office on Droid 4 says the PDF is "damaged".
@LOOPY, I greatly appreciate your efforts, very helpfull.
I revised it with something much better. I can download it or my brower is fooling me. Maybe it is only available in Taiwan.
This version just may lead to some very intelligent discussion about ANS Forth 94 versus PropForth adaptations.
a couple corrections:
c! and c@ are listed as none, maybe these should be listed as renamed C! and C@. Also see W! W@ L@ L!, and COG ! COG@
The words not implemented are ! and @ since cell size is ambiguous
double word support is listed as "not needed", should be "not implemented in kernel"
file and os stuff is listed as "use saveforth" should be "use file system kernels EEPROM or SD"
instead of mod pf has /mod and */mod
there is "leave" on the propforth dictionary
Instead of u.r in propforth there is u. because Sal like to save on r's
tib is not used, but the space 10 bytes(?) after "here" is uses as scratch area (This might have changed recently, I need to check)
create ...Does> is is not used in propforth, we use separate compile time words and run time words.
sp@ and sp0 - there is something in propforth for directly accessing stack elements, but I can't find it at the moment.
That's all I got right now, this is a a very good start.
Concerning @ ! the memory access words: These are usually based on the cell size and date from ancient times when the entire processor was either byte addressable or word addressable, and there was a single memory space. On modern processors, we can address bytes (characters), words, longs, and sometimes double, so this ! and @ alone are no longer adequate. On the prop, the default word size is word in the hub, and long in the cogs, so neither cell size is suitable as default (and so we explicitly define C! C@, W@ W!, L@ L!, COG! COG@ so there would be no confusion). BUT for the purposes of compatibility with "Starting Forth" examples, we could select either word our long, and work in hub or cog space, and be code compatible with the examples. Since the examples are short, and mostly not complete applications, this might work.
OKAY!!!!!!!!!! Finally some good input about specifics rather than a generalized debate about it is not ANS Forth 94 and it is just the way Sal wants it.
c! and c@ versus C! and C@ --- They are indeed the same. It seems I forgot that I shifted all the Starting Forth lexicon from upper case to lower case for automated comparison.
PropForth created the spread of C!, W!, L!, COG!, C@,W@,L@, and COG@ for some reason. Rather than having a cell that is the minimum 16bit size as ANS Forth 94 did, the stack is now 32bit and the cell size is a bit fuzzy. It can be 32bit or 16bit, maybe even 8 bit --- but the Dictionary is certainly not 32bit or 8 bit --- it is 16 bit to add more space and to optimize speed. Why would anyone bother with 16 maths when 32 bit is available?
So a lot of confusion. "Starting Forth describes C! and C@ as store and retrive characters and that does imply a conversion form ASCII to letters - but it may just happen in the dumb terminal. C! and C@ are simply 8 bits.
Double word "not needed" versus double word "not implemented" -- The debate is merely point of view. Is there really a need for 64 bit maths on the Propeller. If I were to desire 64 bit maths, I'd use my Intel Quad 64bit at 2.4Ghz rather than a 32bit Propeller.
Mod versus whatever PropForth does -- Are you saying the same features are just provided in a different way? What does the learner have to relearn and adapt? If you change it, defend the change and teach it to new students. Maybe the ANS Forth 94 way was adequate.
"Sal likes to save the 'r's'" and he also avoids the leading ? or stand alone ? at all costs. That's interesting..... personal flourishes? But Sal simply ignores the fact that formatting number as right justified is a useful tool and needed for presentation.
Dig deep and consider how and why Leo Brodie taught 'Starting Forth' his way; and then consider that you might have to present a contrasting scheme in a similar 12 chapters to adequatly match the ground he covered.
Regarding "leave"... I somehow missed it. It seems that "abort" and "abort?" also exist, but are not listed in the PropForth.htm in Section 9. I may be wrong. But this kind of items might be my error or your omission from documents.
In closing. I am very happy as I am finally making some real headway. There has been a remarkable amount of resistance to investigating different approaches to Forth in detail.
And please, don't tell me again that PropForth doesn't use "Create ... Does>" without telling me what the replacement is. Is this a secret? What is that separate compile time methodology? Is it none of my business?
The short story.... I have investigated further, thought about your input. And so... here is another revision. Working towards a perfect V1.0.
In the old days, we used 16 bit when it is sufficient, and we use 32 bit when we needs it. Now we use 32 bit when id does the job (pretty much everyday) and use 64 or 128 bit when we need it (for calulating course correction on the probe to jupiter, which is a little further down the "to-do" list)
[/QUOTE]So a lot of confusion. "Starting Forth describes C! and C@ as store and retrive characters and that does imply a conversion form ASCII to letters - but it may just happen in the dumb terminal. C! and C@ are simply 8 bits.[/QUOTE]
eliminate the confusion. byte = character. We didn't use "B" for byte because some folks want "B" for bit, we already had that discussion in the '80's (what a pain some folks are). BYTE is 8 bits, character is the old name, we C because character used to be 8 bits.
When you need it, you need it. If you want it, it there with the addition of a simple extension. There need be no debate.
I only look are weird math when I need to use it. We should look at the goes-inta's and the comes-outta's for each definition, and figure where they differ. Then look at the PASM words that can implement each function, we should find that the words implemented were the smallest, most efficient way that they could be done on the prop, and the awkward implementations were skipped.
OK, I saw being a smart @$$. I'm not good at humor. Sal wanted the leave off the R in u.r since it makes no sense to him, and apparently there was a big discussion about this when writing the standard, and the wrong side had the loudest voice. Or something, maybe I just made that up. In anycase, Sal used u. instead of u.r we may redefine this in a single definition if we wish. What does ? do anyway? I never use it, apearently Sal never does either, or it woul be in there. Just write one, it takes 2 seconds.
The world was 16 bit. polyFORTH was the best forth in the world, and there was no standard. People had recently moved out of caves but still worked in silos. Now we have the prop.
I also thought the abort words were present, but maybe Sal saw these as sloppy or unused, or maybe he just forgot them. Please open an issue to put these in, Sal will dig them out or at least tell us what the deal is.
Propforth omits CREATE. DOES> because the dictionary doesn't work that way, AND we prefer separate compile time words and separate run time words. Experts that wish to use CREATE ... DOES> are capable of implementing them. Those not capable of implementing them likely should not use them in the first place, in any case they will just have to wait until the they or somebody else goes to all the trouble (that is really not worth it, but you won't know till you try).
Similar are the return stack words R@ >R R>. These are totally dangerous and you WILL use them wrong the first dozen times or so, but they are needed in creating the dictionary entries so they are included. When things go wonky, its mostly due to in correct return stack word use, incorrect compiletime/runtime behavor word use, or other. We've eliminated the first two biggies, so now we just have to worry about the rest.
I want to define a large number of words with the same kind of action.
Which is formating the name of the word plus a number of stack items to a string and sending this to a serial port.
From the 'learning forth - and the chapter about CREATE ... DOES> and the DEFINING WORDS, my impression was,
that the most effective way for doing this would be to define a new DEFINING WORD 'DefCmd'.
kind of 'DefCmd CMDname' which will generate a new word CMDname ( n1 n2 n3 n4 -- )
Similar to the example of defining the CONSTANT and VARIABLE DEFINING WORDS.
so how would this be done then? in PropForth / or in Tachyon ( where I will need it )
or what would be the 'workaround' doing this with separate compiletime an runtime words?
In propforth, you could look at the code and see how Sal does, and do that. You might have a couple questions, because nobody has asked about till now, and we therefore didn't do that part of the docs (we only do what we guess is needed, and ad as specific questions are asked).
Otherwise, you could look at DPANS94 and see what those words do, and write your own create and does> words to d the same. This is what most folks do on any forth.
If you have trouble, (after you try) just ask here, and we'll try to help you alone. (Me, I have a day job ad they don't let me do non work stuff besides email, so my time is limited).
So, I guess one can make these words themselves, or use other words to do the same thing. Dave Hein mentioned that there was a requirement for a flag to properly have at least one of these words work, and that not providing that flag was part of the reason for their omission.
The comment that CREATE ... DOES> does not exist because 'the dictionary doesn't work that way' seems to indicate that a) these versions are not extensible compiler capable and b) to achieve that goal would require using the kind of dictionary that Dave Hein has been using.
I am really hoping that there is another alternative that I am just missing and that it is just a case of creating some words.
So I am really wondering if this is a relatively minor task of creating a few words, or if it would require a major rebuilding of the dictionary's internal workings. I've not really idea, but I can certain understand why MJB would desire such a feature.
We only have one of the [ and ] words, the ] and that is a bit disconcerting as well.