Thanks for the update. Look forward to seeing something.
I am making steady progress too with a PASM version of FIRST. Just to get an understanding of how it does what it does.
I think everyone who has had a serious look at "first" would agree that there needs to be additional words in the kernel. Its painfullt slow as is but fun to play with.
prof_braino, that's an interesting link. However, it seems like the 3-instruction "Forth" is really just a loader. It seems like a stretch to call it "Forth". The kernel words are basically peek and poke instructions that most simple monitors provide, along with a jump instruction. The real Forth compiler in this case is implemented on a PC.
Your opinion may differ, but consider that this guy is one of the experts. I cite as my evidence pygmy forth, which runs on the PC, and is about as DSPAN94 compliant as can be. pygmy is closest I've seen to the original forth from the source on which the standard was based. This dude know his stuff, he know what forth is, what its used for, and how to use it.
This particular point has no real impact on anything, its just an opinion for consideration in response to Loopy's question .
I wonder what provision you have considered, if any to access cog mem above the kernel and stacks.
Maybe you plan look at this after ANS forth is up and running.
Ron, I'm planning on adding cog! and cog@ words to access cog memory. This will provide access to all of the registers from $1F0 to $1FF, in addition to any other location in cog RAM. I'll probably add a word to execute an instruction from the stack. This will allow doing a WAITCNT, COGNEW or any other cog instruction. Or many I'll implement a simple LMM interpreter. I haven't really gotten to working on that part yet.
I totally agree about that not being a real forth.
It's an extension of forth onto the target platform. The target can be driven in all sorts of ways from the host, and honestly I think it's damn cool. Really neat idea, because it's a very tiny bootstrap one could just type in on a lot of hardware.
A real forth can build words, IMHO. That little three instruction one can't really do that yet.
On P2, the monitor offers those capabilities basically. With some redefinition of core words running on a host forth, a P2 could be driven just as described, though with a bit more verbose interaction. Then again, the serial can be pretty darn fast too.
I have outlined an essay today about 'Ideal Forth' as opposed to real-world solutions (but it is not quite finished). Since Forth's tradition has been to prioritize smallness, speed, and compactness - standard Forth for the sake of mobility of code to another platform may be a significant mis-interpretation of what the Forth standard is about. Also, the reader of the standard may focus far too much on the lexicon, rather than the whole of Forth.
On the other had, we have people that have sailed onward by abandoning the standard in hopes of better versions of Forth and too much may have been jettisoned. Conforming to lexicon makes any new Forth transparent to one's peers. Not doing so, enables the new version of Forth to hide a multitude of sins in semantic complexities.
Peer review can be a good thing.
Regarding size of Forth --- generally and historically a lexicon of about 200 words has been needed and ample to provide a complete optimal Forth, while between 500-600 words have made a rather complete system. But these observations did not include multi-tasking or parallel processing.
I suppose there will be minimalist that will try to create "Forth on a pin head" for intellectual, educational, and recreational purposes. After all, I see quite a few versions of "Mini-chess" played on 4x4, 4x5, 5x5, 5x6, and 6x6 boards. People love to create these things. But in the case of chess, the 'real game' is standard 8x8.
This is interesting, but I sincerely hope we are not going to loose site of some realistic goal. We can just fork software endlessly into uselessness.
We will always have a 'real Forth' (or many 'real Forths') and an ideal Forth. Plato's Alegory of the Cave documented this condition of the human mind over 2500 years ago. Accept it and work with it.
Oh, and a bit of preview....
An ideal Forth can 1. interpret, 2. compile, 3. extended the compiler, and 4. assemble. I am not quite ready to commit to those 4. I need to read more about Forth. And there may be more than 4. But that is a working hypothesis. Added features would be an editor, a file system, multi-tasking, parallel processing, and interface with an OS. Let me know what I've missed.
The bottom line = What good is an ideal or a standard that doing fully exploit the hardware?
There are couple of things about implementing Forth on a multi cog
micro like the Prop that I can't seem get get my head around
I realise I am jumping the gun bit but, do you provide a method to switch STDIO to different cogs on the fly or do you have one forth cog that communicates between the IO cog and the other Forth cogs.
If you choose to do it the PF way you end up having to partition Hub so TIB in the traditional sense of the word goes out the window. How else would you do it?. Sharing a common TIB does not sound like an option to me.
Just imagin 3 forth cogs transferring data via a common dictionary using locking. It really does not work.
1.sd_driver
2.text editor,
3.LCD touch screen driver
4 FulDuplexserial cog (always required)
Alternatively a single Forth cog which communicates with the IO cog and the other forth cogs, would only require a singe TIB . Partitioning hub ram would not be required. (hopefully)
However a small rendezvous area set aside in Hub, for transferring data between cogs. Would probably be requires 256 words + 16 would be perfect for SD_block transfers, but could be used for temporary storage of string etc. Idealy diictionary variables should not be create to be shared across cogs (AKA volatile)
Alternate approach.
sd_driver
text editor,
LCD touch screen driver
FulDuplexserial cog (always required)
forth communications handler (always required in this option)
Everything beyond the bare kernel is extensions. We add extensions until we have enough to do what we want, and then save this as a starting kernel. If we want a general development system on a particular chip, we can stop there. If we want a general solution that is code compatible on all syste4ms, we have to do a little more work.
Mr Sargent shows that from an initial set of words capable of extending the language, any desired set of words can be built.
Interesting, entertaining, and educational.... But when the machine provides hardware features that are faster as primitives, this kind of regime is rather naive. See the thread above for my analogy of min-chess versus regulation tournament chess.
In other words, the 'ideal Forth' would start with a set of goals and features that are useful - not just entertaining, interesting and educational. From there, the creator of a Forth must 'embrace the provided hardware fully'.
Gawd. I am beginning to sould like Master Yoda........
@Ron Sutcliffe
One TIB versus many is very interesting. I suspect PropForth and TachyonForth have created only on Cog image of a VM, whereas you imply that a seperate more compact image might actually be an enhancement.
The Propeller also has a series of locks and unlocks that are required to that Cogs do not clash in reading and writing to and from hub RAM. Would the single TIB approach simply what appears to be a growing matrix of lock and unlock commands?
A rendevous area.... I like the term, how romantic.
@Ron Sutcliffe
I suspect PropForth and TachyonForth have created only on Cog image of a VM
.
Really. I can't even image whats thats supposed to mean. Try this simple test at the PF console.,
From cog 6 where does the PF word "par" point to ?
Now go to another cog and and check "par" again. Now work through the cogs repeating the above. Check out the relationshop between the values returned by "par". from each cog
You might just learn something. Lets know how you get on.
Really. I can't even image whats thats supposed to mean. Try this simple test at the PF console.,
From cog 6 where does the PF word "par" point to ?
Now go to another cog and and check "par" again. Now work through the cogs repeating the above. Check out the relationshop between the values returned by "par". from each cog
You might just learn something. Lets know how you get on.
Ron
"on cog image'' was an insidious typo, it should read ONE cog image, PropForth seems to provide 7 duplicate cogs with one cog image, where as you seem to propose specialized cog images to complete the services.
I will check out 'par'. The dear Professor has buried me in delegated tasks for documenting and promoting PropForth. It may just be the perfect time to drop all that an use what is at hand. I think I have learned enough to study on my own.
~~~~~~~~
And so... I have checked an all the values of par seem to be 496. I also referred to the Propeller Manual 1.2 to read up on 'par'. So other than being able to rotate from cog to cog and read a register in each cog, I have no real idea of what having all the same value implies that is different from my comment that there is ONE cog image that is loaded 7 times.
Okay... a very goood point. I will poke about and try to provide the real value. Methinks that funny COG@ is right for the job.
It seems that maybe all the PropForth words for the 16 registers are just constants to grab the addresses.
~~~~~~~~~~~~~
So far Cog6 par has 2184 as a decimal value, Cog5 par has 1960 as a decimal value. I will proceed down the line.
~~~~~~~~~~
Please don't feel you have to rush to keep up with me. I learned something of value, i.e. -- A lot of these odd ball terms in PropForth are useful constants and not to be feared as complex words.
Sorry loopy
Too early in the morning for me, I should have said pad>in not par. The excercise is still worth doing because you can calcuted the total partition size from that.
PF fully partitions Hub, not the best solution IMO, A lot of Hub is wasted.
Back to pfth (thats what this thread is about..)
I thought a single TIB was worth considering at this early stage. All 7 cogs are still forth cogs, (running the same kernel), but one forth cog would be used to transfer data from STDIO cog to the other cogs. You loose an extra cog.
Now because this dedicated cog is written in Forth, it could be modified by the user. If that idea has any merit (thats for David to decide) he may need to take it into consideration at the kernel design stage.
Yes par points to the partion dedicated to that cog, but seeing that we discussing TIB I ment pad>in. Anyway you have learnt something. See what happens when you use Forth interactively.
Beats reading reams of docs
@RON
Thanks. I really don't want to highjack this thread for a personal lesson and I may have gotten a bit over my head about the TIB. I am just very interested in the progress of pfth.
No need to reply. It is all rather embarrassing as I got into Forth because PF 5.0 was supposed to have rather complete docs. And now I seem to see that as chasing rainbows. I am beginning to see that if one finds a Forth that works, just use it until you learn enough on your own to make it better.
I don't have a make file, but I just use "gcc pfth.c words.c -o pfth" on the command line.
That works - thanks.
On my machine (FreeBSD 8.3-stable), the compile produced this warning:
words.c:1462: warning: cast to pointer from integer of different size
/var/tmp//ccIhefbJ.o(.text+0xf5d): In function `main':
: warning: warning: this program uses gets(), which is unsafe.
The gets() function cannot be used securely. Because of its lack of
bounds checking, and the inability for the calling program to reliably
determine the length of the next incoming line, the use of this function
enables malicious users to arbitrarily change a running program's func-
tionality through a buffer overflow attack. It is strongly suggested
that the fgets() function be used in all cases.
I wonder if it is the same on Linux and other platforms too?
Regarding gets() versus fgets()...
If there is only one users, does this really create an issue? The warning applies to security needs of a multi-user system. Linux is indeed a mult-user system, so the protection might apply to that, but not to Forth on a Propeller.
fgets() protects against buffer overflows, so it is preferred over gets(). However, the security issue is normally related to applications that are accessed through a network connection.
The attached zip file contains pfth version 0.45. This version contains a PASM version of pfth. Less than 50 kernel words are implemented in PASM in pfth.spin, and the remaining words are implemented in init.fth. PASM pfth runs much faster than the C version of pfth. The RC4 code that is in the Forth Wikipedia entry runs about 50 times faster in PASM. You can run PASM pfth by compiling pfth.spin in the Prop tool or BST, and loading it into any Propeller board.
I just downloaded PropTools again, Now my Prop plug is found on Com27 was Com 7. My Favourite Tera Term console does not look for com ports over 16 (even though you can set max ports to 32 and set the com port to 27 in the config file ) Anyway it works on PST (com27) but will test later when I fix this Windoze Register. I assuming thats where the problem is.
The attached zip file contains pfth version 0.45. This version contains a PASM version of pfth. Less than 50 kernel words are implemented in PASM in pfth.spin, and the remaining words are implemented in init.fth. PASM pfth runs much faster than the C version of pfth. The RC4 code that is in the Forth Wikipedia entry runs about 50 times faster in PASM. You can run PASM pfth by compiling pfth.spin in the Prop tool or BST, and loading it into any Propeller board.
Finally, I get the chance to sit down and try this. Two minutes flat and I'm working through "Starting Forth"! Joy. Thanks Dave.
Much to learn from here: work back and study C, PASM, compiler/interpreter implementation and such. Or continue to go FORTH (pun intended).
Hurray! You can't keep a good man down by telling him not to try something. I have been downloading and saving all your .zip files from 011, but haven't had time to load any yet as PropForth has been keeping me busy.
I still love to see the evolution from C to PASM of a very close to ANS Forth 94,
I now see that as one adapts to speed, the visibilty of the code becomes more opague. You start out in C to verify your construtions and then recode in PASM.
And I see that mainly beginners expect to rely on documentation, the good source code with comments will likely trump any documentation good or bad in the long run. I absolutely much improve my knowledge of PASM, as well as C.
Learning Forth well may just turn out to be a rather advanced topic. I don't quite see how to make Forth on a microcontroller really useful without some ability to code and recode in assembly language.
David
Just a small thing I noticed in the PASM version, is that on boot
OK
If you Enter something like 20 cog@ .S
Forth will return adr in hex and the contents in dec. AKA .1b 12345678
Its Ok, but a little confusing. The C version works fine (no access to Cog adr's) I built from source.
If you are going to move serial coms out of the cog in the PASM version later I will sit on me hands, otherwise. I will make some changes to my copy of the file so that I can run two copies of the kernel with a common FDS Cog then I can play around with a few ideas.
The .s command should print <1> instead of '1b. There's a bug in the definition of the word ".s" in init.fth, where it is using the decimal values of 60 and 62 for the ASCII characters "<" and ">". The values should be written in hex as 3c and 3e. The bug occurred because init.fth is a modified version of ansi.fth, which is used with the C version of pfth. When PASM pfth starts up it compiles init.fth in the hex mode because I use _gethex to convert numbers.
I've also found a problem with "/" and "mod" for negative numbers. The attached file fixes these problems, and also adds the "see" command. Just copy pfth.spin, init.fth and see.fth from the zip file to your working directory.
@ David
The issues from a developers perspective is that pfth cog uses the internal getch1, once the bootx has built the forth dictionary (pretty neat "first" implementation). It would be nice to have identical forth kernels which can be loaded into all cogs. The way it looks at the moment, another version of the kernel will be required for the other cogs. These cogs would not need to build the Forth dictionary, given that it is shared. and getch ( no getch1 required) could get data from a reserved area in hub. This would have the advantage of being able to pass data between cogs without using the dictionary. NO Dict-locks. The "aux" kernels would be smaller.
PF uses a small loader in the kernel, which when it sees the "fl 0d" normally the first line of any PF.fth, it starts the next available cog and buffers the data pasted to the console. It is compiled from there to the dictionary. This means that you can select all, copy text from a plain text file on your PC and paste to the forth console. The fact that pfth does not have a saveforth word does not bother me because once tested in can be included in the data section of the pfth.spin file. ATM the process is clumsy.
I plan to add a COGX kernel word that will execute a PASM instruction. Using this along with cog@ and cog! will allow doing things like cognew, waitcnt, and so on. A new Forth cog could be started by patching the pfth cog image in hub RAM before starting a new cog. The new cog could run a pre-compiled word, and avoid using console input.
Comments
I am making steady progress too with a PASM version of FIRST. Just to get an understanding of how it does what it does.
I think everyone who has had a serious look at "first" would agree that there needs to be additional words in the kernel. Its painfullt slow as is but fun to play with.
Your opinion may differ, but consider that this guy is one of the experts. I cite as my evidence pygmy forth, which runs on the PC, and is about as DSPAN94 compliant as can be. pygmy is closest I've seen to the original forth from the source on which the standard was based. This dude know his stuff, he know what forth is, what its used for, and how to use it.
This particular point has no real impact on anything, its just an opinion for consideration in response to Loopy's question .
Maybe you plan look at this after ANS forth is up and running.
It's an extension of forth onto the target platform. The target can be driven in all sorts of ways from the host, and honestly I think it's damn cool. Really neat idea, because it's a very tiny bootstrap one could just type in on a lot of hardware.
A real forth can build words, IMHO. That little three instruction one can't really do that yet.
On P2, the monitor offers those capabilities basically. With some redefinition of core words running on a host forth, a P2 could be driven just as described, though with a bit more verbose interaction. Then again, the serial can be pretty darn fast too.
On the other had, we have people that have sailed onward by abandoning the standard in hopes of better versions of Forth and too much may have been jettisoned. Conforming to lexicon makes any new Forth transparent to one's peers. Not doing so, enables the new version of Forth to hide a multitude of sins in semantic complexities.
Peer review can be a good thing.
Regarding size of Forth --- generally and historically a lexicon of about 200 words has been needed and ample to provide a complete optimal Forth, while between 500-600 words have made a rather complete system. But these observations did not include multi-tasking or parallel processing.
I suppose there will be minimalist that will try to create "Forth on a pin head" for intellectual, educational, and recreational purposes. After all, I see quite a few versions of "Mini-chess" played on 4x4, 4x5, 5x5, 5x6, and 6x6 boards. People love to create these things. But in the case of chess, the 'real game' is standard 8x8.
This is interesting, but I sincerely hope we are not going to loose site of some realistic goal. We can just fork software endlessly into uselessness.
We will always have a 'real Forth' (or many 'real Forths') and an ideal Forth. Plato's Alegory of the Cave documented this condition of the human mind over 2500 years ago. Accept it and work with it.
Oh, and a bit of preview....
An ideal Forth can 1. interpret, 2. compile, 3. extended the compiler, and 4. assemble. I am not quite ready to commit to those 4. I need to read more about Forth. And there may be more than 4. But that is a working hypothesis. Added features would be an editor, a file system, multi-tasking, parallel processing, and interface with an OS. Let me know what I've missed.
The bottom line = What good is an ideal or a standard that doing fully exploit the hardware?
Looks like you are on roll.
There are couple of things about implementing Forth on a multi cog
micro like the Prop that I can't seem get get my head around
I realise I am jumping the gun bit but, do you provide a method to switch STDIO to different cogs on the fly or do you have one forth cog that communicates between the IO cog and the other Forth cogs.
If you choose to do it the PF way you end up having to partition Hub so TIB in the traditional sense of the word goes out the window. How else would you do it?. Sharing a common TIB does not sound like an option to me.
Just imagin 3 forth cogs transferring data via a common dictionary using locking. It really does not work.
1.sd_driver
2.text editor,
3.LCD touch screen driver
4 FulDuplexserial cog (always required)
Alternatively a single Forth cog which communicates with the IO cog and the other forth cogs, would only require a singe TIB . Partitioning hub ram would not be required. (hopefully)
However a small rendezvous area set aside in Hub, for transferring data between cogs. Would probably be requires 256 words + 16 would be perfect for SD_block transfers, but could be used for temporary storage of string etc. Idealy diictionary variables should not be create to be shared across cogs (AKA volatile)
Alternate approach.
sd_driver
text editor,
LCD touch screen driver
FulDuplexserial cog (always required)
forth communications handler (always required in this option)
Just my two cents worth.
Interesting, entertaining, and educational.... But when the machine provides hardware features that are faster as primitives, this kind of regime is rather naive. See the thread above for my analogy of min-chess versus regulation tournament chess.
In other words, the 'ideal Forth' would start with a set of goals and features that are useful - not just entertaining, interesting and educational. From there, the creator of a Forth must 'embrace the provided hardware fully'.
Gawd. I am beginning to sould like Master Yoda........
One TIB versus many is very interesting. I suspect PropForth and TachyonForth have created only on Cog image of a VM, whereas you imply that a seperate more compact image might actually be an enhancement.
The Propeller also has a series of locks and unlocks that are required to that Cogs do not clash in reading and writing to and from hub RAM. Would the single TIB approach simply what appears to be a growing matrix of lock and unlock commands?
A rendevous area.... I like the term, how romantic.
Really. I can't even image whats thats supposed to mean. Try this simple test at the PF console.,
From cog 6 where does the PF word "par" point to ?
Now go to another cog and and check "par" again. Now work through the cogs repeating the above. Check out the relationshop between the values returned by "par". from each cog
You might just learn something. Lets know how you get on.
Ron
"on cog image'' was an insidious typo, it should read ONE cog image, PropForth seems to provide 7 duplicate cogs with one cog image, where as you seem to propose specialized cog images to complete the services.
I will check out 'par'. The dear Professor has buried me in delegated tasks for documenting and promoting PropForth. It may just be the perfect time to drop all that an use what is at hand. I think I have learned enough to study on my own.
~~~~~~~~
And so... I have checked an all the values of par seem to be 496. I also referred to the Propeller Manual 1.2 to read up on 'par'. So other than being able to rotate from cog to cog and read a register in each cog, I have no real idea of what having all the same value implies that is different from my comment that there is ONE cog image that is loaded 7 times.
Loppy I will post something for you later
Ron
It seems that maybe all the PropForth words for the 16 registers are just constants to grab the addresses.
~~~~~~~~~~~~~
So far Cog6 par has 2184 as a decimal value, Cog5 par has 1960 as a decimal value. I will proceed down the line.
~~~~~~~~~~
Please don't feel you have to rush to keep up with me. I learned something of value, i.e. -- A lot of these odd ball terms in PropForth are useful constants and not to be feared as complex words.
Too early in the morning for me, I should have said pad>in not par. The excercise is still worth doing because you can calcuted the total partition size from that.
PF fully partitions Hub, not the best solution IMO, A lot of Hub is wasted.
Back to pfth (thats what this thread is about..)
I thought a single TIB was worth considering at this early stage. All 7 cogs are still forth cogs, (running the same kernel), but one forth cog would be used to transfer data from STDIO cog to the other cogs. You loose an extra cog.
Now because this dedicated cog is written in Forth, it could be modified by the user. If that idea has any merit (thats for David to decide) he may need to take it into consideration at the kernel design stage.
Beats reading reams of docs
Thanks. I really don't want to highjack this thread for a personal lesson and I may have gotten a bit over my head about the TIB. I am just very interested in the progress of pfth.
No need to reply. It is all rather embarrassing as I got into Forth because PF 5.0 was supposed to have rather complete docs. And now I seem to see that as chasing rainbows. I am beginning to see that if one finds a Forth that works, just use it until you learn enough on your own to make it better.
On my machine (FreeBSD 8.3-stable), the compile produced this warning: I don't know why it complains about gets().
If there is only one users, does this really create an issue? The warning applies to security needs of a multi-user system. Linux is indeed a mult-user system, so the protection might apply to that, but not to Forth on a Propeller.
I just downloaded PropTools again, Now my Prop plug is found on Com27 was Com 7. My Favourite Tera Term console does not look for com ports over 16 (even though you can set max ports to 32 and set the com port to 27 in the config file ) Anyway it works on PST (com27) but will test later when I fix this Windoze Register. I assuming thats where the problem is.
Like the documentation too.
ron
Finally, I get the chance to sit down and try this. Two minutes flat and I'm working through "Starting Forth"! Joy. Thanks Dave.
Much to learn from here: work back and study C, PASM, compiler/interpreter implementation and such. Or continue to go FORTH (pun intended).
I still love to see the evolution from C to PASM of a very close to ANS Forth 94,
I now see that as one adapts to speed, the visibilty of the code becomes more opague. You start out in C to verify your construtions and then recode in PASM.
And I see that mainly beginners expect to rely on documentation, the good source code with comments will likely trump any documentation good or bad in the long run. I absolutely much improve my knowledge of PASM, as well as C.
Learning Forth well may just turn out to be a rather advanced topic. I don't quite see how to make Forth on a microcontroller really useful without some ability to code and recode in assembly language.
Just a small thing I noticed in the PASM version, is that on boot
OK
If you Enter something like 20 cog@ .S
Forth will return adr in hex and the contents in dec. AKA .1b 12345678
Its Ok, but a little confusing. The C version works fine (no access to Cog adr's) I built from source.
If you are going to move serial coms out of the cog in the PASM version later I will sit on me hands, otherwise. I will make some changes to my copy of the file so that I can run two copies of the kernel with a common FDS Cog then I can play around with a few ideas.
Ron
Got my Tera Term back.............Windoze
Ignor my comments, the adr should not be on the stack anyway.
Its clicked.... it's its the items on the stack 0b, 1b,,2b etc
I've also found a problem with "/" and "mod" for negative numbers. The attached file fixes these problems, and also adds the "see" command. Just copy pfth.spin, init.fth and see.fth from the zip file to your working directory.
I am prepring some queries/comments that I have and will post them over the weekend, now that I worked through your spin file again.
The issues from a developers perspective is that pfth cog uses the internal getch1, once the bootx has built the forth dictionary (pretty neat "first" implementation). It would be nice to have identical forth kernels which can be loaded into all cogs. The way it looks at the moment, another version of the kernel will be required for the other cogs. These cogs would not need to build the Forth dictionary, given that it is shared. and getch ( no getch1 required) could get data from a reserved area in hub. This would have the advantage of being able to pass data between cogs without using the dictionary. NO Dict-locks. The "aux" kernels would be smaller.
PF uses a small loader in the kernel, which when it sees the "fl 0d" normally the first line of any PF.fth, it starts the next available cog and buffers the data pasted to the console. It is compiled from there to the dictionary. This means that you can select all, copy text from a plain text file on your PC and paste to the forth console. The fact that pfth does not have a saveforth word does not bother me because once tested in can be included in the data section of the pfth.spin file. ATM the process is clumsy.
Just my 2 cents worth
Ron