I think I have a pack of SR04's hiding someplace. If I find them, I can try hooking them up to a Quickstart and checking results.
PROPFORTH 6 - Multitasking?? Double cool!! Cooperative or preemptive? Multiprocessor multitasking is FUN!! Once you get things set up by a lead processor (COG), you can let the processors (COGs) go through the prioritized task tree and pick off he most appropriate thing for them to work on next. You create a lockable data structure for he work queue and a short piece of protected code to do the task selection and everybody starts humming away doing work. Back in my old Sperry days, we did this all the time. For a while, I worked on the dispatching code in the operating system. It was one of the coolest places to work in the operating system, I thought.
P2 should make this really confusing when you can have multi-COG, multitasking on multithreaded COGs!!
SR04's ... hooking them up to a Quickstart and checking results.
PROPFORTH 6 - Multitasking?? ... Cooperative or preemptive?
Thanks! Rick can be Beta tester 1. Sal wants feedback on how well it works (or not) and how to do it better. You insight on how these things work is the input he is seeking.
Sal's scheme is being tested on Prop 1, but is designed for Prop 2. Prop 2 will have 8 cogs times 4 threads per cog, so there will be 32 execution opportunities. Sal's scheme (so far) is simple: When an execution opportunity is finished, the task is transfered to the next available execution opportunity. All the threads are assigned to one of more "pools". The time critical tasks always jump to an available thread; the non time critical tasks wait until a thread is available. The developer just has to allocate sufficient threads to a pool to make it real time or background. If a thread goes down, we only loose 1/32 of processing ability. The overhead is minimal, so the multitasking shouldn't cost too much. But we'll get better numbers in beta test.
On Prop 1 there are only the eight threads (1 per cog) but it should be sufficient to see if it works and compare to non-multitasking PF5.5.
I have already gone through the documentation, including the PropForth.htm.
What is the right condition for a TRUE in PropForth, only -1 or any non-zero number? False is always Zero.
ANSI Forth is any non-zero number, but the only mention of TRUE in PropForth seems to be specifically a -1, except for Zero and Carry flag true conditions (which are a binary bit 1).
I have already gone through the documentation, including the PropForth.htm.
What is the right condition for a TRUE in PropForth, only -1 or any non-zero number? False is always Zero.
ANSI Forth is any non-zero number, but the only mention of TRUE in PropForth seems to be specifically a -1, except for Zero and Carry flag true conditions (which are a binary bit 1).
I think any non zero is true. Something about comparison for fuzzy logic, but we did not do anything with that yet.
And so. It seems that you are unsure. A bit fuzzy, are we? Seems you don't know, or are reluctant to commit.
-1 is 'most' true
1 might be true, or any number other than zero may be true.
Please ask Sal and document the reality. Or do you want me to file a formal request in your Google site?
Of course, I could test all the code that uses t/f with all 32 bits of numbers, but that might take a bit of time.......................................................................................
And so. It seems that you are unsure. A bit fuzzy, are we? Seems you don't know, or are reluctant to commit.
-1 is 'most' true
1 might be true, or any number other than zero may be true.
Please ask Sal and document the reality. Or do you want me to file a formal request in your Google site?
Of course, I could test all the code that uses t/f with all 32 bits of numbers, but that might take a bit of time.......................................................................................
OK, let me rephrase that. I am absolutely 100% positive that 0 is false and any non zero is not false, because I use this all the time.
This is how TRUE and FALSE are defined:
9.1.46 -1
\ -1 or true, used frequently
9.1.53 0
\ Word constant, 0 or false, used frequently
That is the extent Sal wanted to define it because:
There are lots of cases where the logic comes from a single bit, so we can NOT strictly say that -1 is true. So, in accordance with normal forth rules, zero is false, and everything else is derived from "zero or other". We can use any non zero value to be true if we want to be tricky, but generally we should not be tricky. It gets to be a grey area, which is why it works for fuzzy logic. There was not really a good way to make a definitive statement about the grey parts.
So -1 = TRUE. 0 = FALSE. Beyond that we are on our own. Unless you can sort out a good way to say this clearly.
@Prof Braino
Yes we are both sure that PropForth always has 0 = False.
I think I made the question quite clear. Either you don't know or do know.
A. True is limited to -1 only
B. True is any number other than Zero
This is not rocket science, and it certainly isn't 'fuzzy logic'. It is just something that is usually stated clearly in any Forth specification.
Can you give me a concise reference to where PropForth specifies that only -1 is True? Or a concise reference that any number other than 0 is accepted as True? Or, are you just shooting from the hip? All I can do is infer that that might be true.
Your quote that "-1, used frequently" just clouds the issue. When I test the following....
: test begin ." testing" cr 244 until ." out of loop " cr ;
I get behavior indicative of B, not A occurs at least some of the time.
This behavior is both standard Forth and useful.
Why assert that only -1 is acceptable? That certainly is not historically Forth. It just is confusing.
Your referance about the constant -1 just explains why the -1 constant was created... as a 'true indicator'. BUT it is one of many 'true indicators'. The .htm is full of omissions of topics that are quite important... very Beta.
@Prof Braino
Yes we are both sure that PropForth always has 0 = False.
I think I made the question quite clear. Either you don't know or do know.
A. True is limited to -1 only
B. True is any number other than Zero
This is not rocket science, and it certainly isn't 'fuzzy logic'. It is just something that is usually stated clearly in any Forth specification.
Can you give me a concise reference to where PropForth specifies that only -1 is True? Or a concise reference that any number other than 0 is accepted as True? Or, are you just shooting from the hip? All I can do is infer that that might be true.
Your quote that "-1, used frequently" just clouds the issue. When I test the following....
: test begin ." testing" cr 244 until ." out of loop " cr ;
I get behavior indicative of B, not A occurs at least some of the time.
This behavior is both standard Forth and useful.
Why assert that only -1 is acceptable? That certainly is not historically Forth. It just is confusing.
Your referance about the constant -1 just explains why the -1 constant was created... as a 'true indicator'. BUT it is one of many 'true indicators'. The .htm is full of omissions of topics that are quite important... very Beta.
I humbly suggest that this one gets resolved.
Can I chip in and fill you in on what is true and what is false
First off, any non-zero is accepted as a TRUE if it's involved in a conditional branch such as IF or UNTIL or WHILE. The reason that a -1 is preferred is when it comes to performing Boolean operations on true/false flags. Just imagine that you have two TRUE flags on the stack but one happens to be $20 and the other $01. Now if you try to AND two trues you should get a true except in this case you end up with a false because AND is a logical bitwise operation and does not know to perform a Boolean AND. The way around this is to convert non-Boolean flags to Boolean by a simple 0<> operation.
BTW, the analogous operation in PASM is the zero status, it's either zero or it's not zero which is fine to use for a branch condition but don't assume you can just perform logical operations to get a Boolean result.
Thanks Peter.. that is an intelligent explanation, and helpful. You actually taught me something very useful.
I did grasp that -1 for True is useful in a specific context, but couldn't find what context or why.
I was looking for an answer to the actual behavior of PropForth as I am debugging some odd code behavior,.... not an interpretation of constant entries of the unfinished PropForth.htm document.
According to PB's interpretation of that text
"9.1.53 0
\ Word constant, 0 or false, used frequently"
might actually imply that there are more than one False condition as well.
After all, that would be much more consistent when you apply that there is more than one True condition to the following:
'9.1.46 -1
\ -1 or true, used frequently"
~~~~~~~~~~~
Some people love to march through version releases, others are very frugal. Beginners beware.
My sense of PropForth v5.5 is really a reasonable v0.95 in the real world. There is a lot that is right and useful -- even interesting, but it just isn't ready for the complete beginners.
Since it asserts its non-ANSI Forth status, it is often hard to know what is what as the author has never presented a rationale.... just a warning.
Having documentation clarify the non-ANSI Forth features would be a great aid. I wouldn't have to dig and guess. Less digging and guessing converts into more popularity. This stuff is daunting.
One of the advantages of conforming to a standard is that things like this are clearly documented in the standard. It might be useful to create a document for PropForth that contains the same level of information that is in the ANS Forth standard. I can understand that it might be hard to be motivated to write such a document since it would only be read by a handful of programmers, but it seems like a useful exercise. At least with ANS Forth there are probably several hundred programmers that use the standard document.
Can I chip in and fill you in on what is true and what is false .....
BTW, the analogous operation in PASM is the zero status, it's either zero or it's not zero which is fine to use for a branch condition but don't assume you can just perform logical operations to get a Boolean result.
... the actual behavior of PropForth as I am debugging some odd code behavior,....
Maybe ask the spcific question? "I'm doing this and see this, what is X?"
It might be easier to answer.
" Word constant, 0 or false, used frequently"
might actually imply that there are more than one False condition as well.
You are confusing two issues. The "used frequently" is the answer to "why define -1 as a constant when its already a number?" This is because the check for number happens LAST. Defining often used numbers as constants cuts down compile and build time significantly, at least enough for Sal to decide to add these entries to the dictionary.
My sense of PropForth v5.5 is really a reasonable v0.95 in the real world.
All it needs is the documentation you are sorting out. I will post it as soon as you finish it.
There is a lot that is right and useful -- even interesting, but it just isn't ready for the complete beginners.
Actually, it what you already know that gets in your way. You assume it does a stuff you expect from other environments, but it doesn't. Propforth just does what it says and the rest isn't defined. We can figure out what the undefined stuff does, but that doesn't necessarillly make it a requirement or fit any specification. We would have to make those decisions when we examine any given issue.
Having documentation clarify the non-ANSI Forth features would be a great aid. I wouldn't have to dig and guess. Less digging and guessing converts into more popularity. This stuff is daunting.
We're all looking forward to this clarification. I for one will review it and try to make useful comments when you post the draft, but much of this stuff is beyond me.
Most participants on these forums are experts on all aspects of technology, but remember, all I do is check that the stuff we say should be tested got tested, and what were the results. That is the full extent of my value-add.
That is an excellent idea. Start writing it and we can review it, and fill in any missing bits.
I see little motivation for doing this myself, but I thought you might be interested in doing it. I thought writing documentation was your thing. A document at the level of the ANS standard document would be beneficial to the people that use PropForth. It would eliminate the uncertainty about things like how logic values work. This is part of the problem with creating your own dialect of a language. You have to document everything yourself instead of taking advantage of the work that others have done when creating a standard.
"All it needs is the documentation you are sorting out. I will post it as soon as you finish it."
@ Prof Braino
Please don't presume I am writing or editing documentation for the PropForth. I explained in December that I felt it was beyond my doing so for several reasons - physical limitations and intimate knowledge of PropForth.
These days, I see that V5.5 package removed much of the source code. I've no idea of how to keep up with all this. You removed the V5.0 that had all the reference material from the downloads.
I am just doing a little project to evaluate the status of V5.5 and to extend my knowledge a bit.
It is not going to happen. If you were Tom Sawyer, you'd just have to paint your own fence. Nice try.
"These days, I see that V5.5 package removed much of the source code.
If you were Tom Sawyer, you'd just have to paint your own fence. Nice try.
Geez. This again. Loopy in his mood. Please note
* ALL THE SOURCE IS INCLUDED IN THE DOWNLOAD, IT ALWAYS HAS. Please look in the misc directory, and find the my-goXXX.zip. This is the exact download as in 5.0, moved to a subdirectory to make it easier for new folk to find the burn and go kernels, as requested. The "hard" stuff is hidden here to keep it out of the way of new folks. But it is always included.
* The documentation is in the state its in for the exact reasons you state, we don't have time and nobody reads it anyway. Questions drive the documentation, demands less so.
* The stuff you ask for is already there. If you don't like it, fix it, or not. Simply complaining doesn't move it in any direction, I don't know what to change. Sorry, I'm just the receptionist.
Never have understood why I had to use MyGo... a Google mobile service to learn. Having started with the pre-MyGo era, I wasn't aware that I had join MyGo to continue to use PropForth.
It seemed to me that MyGo was just an added layer of distraction in the form of 'yet another social networking approach'. I don't have Twitter, I don't have Facebook, and for roaming internet I use a wifi link and a netbook.
Maybe in your ReadMe.txt, you might explain what is both NEW and Necessary. This is just a suggestion.
My frustrations have been due to finding that PropForth seems to have so many places to look to find facts. And so many hard-to-decypher terms to interpret along the way.
At this point, I really don't want to be part of the PropForth developmental agenda, certainly don't want to be part of any promotional agenda... just trying to glean How To info from the user community. And I'd prefer not having to get involved with secondary promotions, like Google's MyGo... just to use something.
@Prof Braino
If I irk you, just let others provide answers to me. Please don't feel that every request for PropForth info is directed to you personally. LIve and let live.
You might take a look at how the Propeller Manual deals with "Logical Constants" for a clearer discussion of True as -1, and False as 0. Of course, the Forth community still asserts that False is always 0 and True is any number that is not 0. You might make mention of that as well. And if you desire to reach a broader audience, you are just going to have to teach more fundamentals. Experts are busy being experts and less curious unless there is a big benefit.
Never have understood why I had to use MyGo... a Google mobile service to learn. Having started with the pre-MyGo era, I wasn't aware that I had join MyGo to continue to use PropForth.
Loopy, You DON'T have to learn or use Go, ITS JUST THE NAME OF THE ARCHIVE AND DIRECTORY WHERE THE SOURCE IS. Rename it if it displeases you.
So far, All your questions have been answered. 0 is FALSE; -1 is TRUE, non zero is also evaluated to true, but just be aware that true defined as -1. Simple, and typical for forth.
We only have a limited amount of resources, these are spent on essentials only. The rest is left to the folks that want those extras. You are free to ignore your own request.
* Without specific changes (add this paragraph on true, change this section to include this) I have no change to make.
* If you open an issue, at least we can track it and review options for any changes. If not, it gets lost.
* If you don't contribute the additional material and changes you demand, it might take a while.
* Responding to answers with a complaint instead of something constructive doesn't make it easier to give you what you want.
things like this are clearly documented in the standard. PropForth ... the ANS Forth standard.
Propforth uses the ANS Forth standard which says, IF YOU CHOOSE to implement this word, this is how the standard defines it. The developer is free to make any deviation required.
I see little motivation for doing this myself, but I thought you might be interested in doing it. I thought writing documentation was your thing.
Thanks! When I run out of extra work, this will be on the top off the list.
A document at the level of the ANS standard document would be beneficial to the people that use PropForth. It would eliminate the uncertainty about things like how logic values work. This is part of the problem with creating your own dialect of a language. You have to document everything yourself instead of taking advantage of the work that others have done when creating a standard.
As stated, we use the ANSForth standard, and supplement this with Propfroth.htm for differences; these are due to the prop architecture. Between these we cover 90% of what folks ask. The remainder are addressed in a case by case basis, when and if they arise. So far the users have generated about 200 issues, and changes from these are rolled into subsequent releases as possible.
Remember the audience for these docs is estimated at about 20 people. And the last 10% tends to be the "tough" parts that people just don't get, any docs tend to make matters worse, one on one mentoring is most effective. How much more effort on docs would you think is reasonable?
I think you have spent enough time on documenting PropForth, so I don't think it's reasonable to spend any more effort on it.
I agree with Dave. Enough said.
Yes I've been grumpy as I tried to prepare a question that was of the form "Is it A behavior or B behavior?" and I got, a 'A because it is mostly true' and ' B might work if you want fuzzy logic.'
I am still confused about the roles of Go language and MyGo. I tend to feel that PropForth keeps moving ahead ambitiously without resolving presentation of some of the more fundamental topics.
In all fairness, I do have similar issues with TachyonForth, but it has had a much shorter existence. It is just hard to keep up with fast changing software in the earlier stages of development.
Dave's 'pfth' is the newest of the newcomers, but he has tried to dodge the paperchase of documentation by conforming to the ANSI Forth standard. That has seemed very prudent as there are several good texts and tutorials available on line for free.
I still love the idea of an excellent interpreted language for the Propeller, and I enjoy Forth.
I am just NOT comfortable with seeking out answers in PASM when I have no place else to go. But even that is changing. Unlike the original Propeller Tool, BST (Brad's Spin Tool) offers detailed and complete Compiler listings that will allow me to sort out actually memory maps on my own.
I am still confused about the roles of Go language and MyGo.
Ask a specific question and I can try to answer it. Make a statement, I can't help you much, as what's already been said covers it.
Remember this is a very powerful, professional tool, and I only know amature, beginner stuff. Maybe ask Peter or Nick directly if I can't answer clearly.
Also, some stuff just might be too "out there" for us to get with a lot of effort on our part. It might just take more time and experience before the light goes on. Happens to me all the time.
I am still confused about the roles of Go language and MyGo. I tend to feel that PropForth keeps moving ahead ambitiously without resolving presentation of some of the more fundamental topics.
Go isn't any grand Google conspiracy to take over the programming world. It is an interesting implementation of a language oriented at system level programming. It has some interesting (and I think very nice) features that make it easier to program than C. Sal started playing with it when the experiments with Communicating Sequential Processes and multi-channel PC to Prop communication were going on. It has features that make this easy to implement and Sal used it to develop some tools. My understanding is that these tools stuck and made the build/test/verification process of PropForth releases easier. I like Go, it's very powerful on a PC but it has a large runtime footprint, so it is limited to being a PC/server language.
MyGO is simply the directory where all the Go code is put. When you install Go, you need to tell it a folder where it will find your source code and package modules and where in can put the binaries it creates. Sal and Doug started calling that MyGo on their PCs when they started playing. It's not a magic name that when found on a PC links it to Google central so it can dump it's brains to the mother cloud. It's just a name. On my Mac, I think the folder is just Go, on my PC, I forgot what I called it but it isn't MyGo. It's just like my folder "node" where my node.js code and packages go or workspace where eclipse puts my Java stuff. Just names, nothing else, nothing sinister.
When I get a new PropForth release, one of the first things I do is create a folder called sourcefiles at the top level of the package (.../v5.5/sourcefiles ) and then I find all the *.f files in anywhere in the package and copy them to this file. That way, no matter where something might be buried for building., testing or whatever, I have it in my sourcefiles so I can find it, refer to it, borrow snippets of code from it, etc. I also run my indexer against it so I can find word definitions within this folder.
Between the *.f files and the .spin kernel files, I go digging for answers when I get puzzled. If I were a good member of the community, I'd document each answer that I find.....I'm generally a bad citizen and don't document much.
I tend to feel that PropForth keeps moving ahead ambitiously without resolving presentation of some of the more fundamental topics.
Both Tachyon and PRopForth are tools of their creators. They follow the whims and needs of their creators and we're just along for the ride. They have decided to share their creations, since this a free donation of their time and passion, I feel they have no obligation to meet our demands for documentation or support. If I can benefit from their contribution through increased productivity or entertainment and mental stimulation, I'm that much richer. If I can't benefit, that's not their fault they don't owe that to me for the price I've paid. If either were a product I had purchased, then I would expect answers when asked and adequate documentation to answer most things I sought information on. As it is, I think Doug does a great job interfacing with Sal and being the visible face of PropForth on the forums. Peter has always been wonderfully helpful and responsive to Tachyon questions and problems and both camps are seriously moving their tools forward with interesting enhancements and features.
My point of view is very simple. If I am learning Forth, I'd prefer not having to include learning yet another language as part of the process of learning Forth.
I seems obvious to me. Go may be handy, interesting, and powerful.... but all those things seem to offer even more distraction to me.
One can't know every language that comes into vogue. And some of us have different goals. For myself, Forth is appealing to peek and poke into the underlying Propeller architecture in an interactive mode. I've gotten into considering remote and mobile computing in the past, but find I have too many things going on in too many places.
My feelings are that Forth has a place in helping new users master what they can do with 8 Cogs... and that may be its greatest value.
Peter and Sal and Dave are all way ahead of me in terms of skills.
~~~~
BTW, regarding the fundamentals behind why zero = false, and all other numbers = true, it seems quite obvious in PASM that all the assembly words that test for any sort of Branch construction and any sort of Jump (that might be used as a Loop) are testing the Zero Flag. It can only see Zero and NOT Zero.
Since it is the most efficient code to do loops and branches, there is no reason to limit these to just a -1 =True. After all, there are many situations where one might want an Unsigned number to be True. And the number can be a Long, Word or Byte. The -1 True Constant might be to one size tied to the Forth Cell size.
Admittedly this is all speculation, but if I can read the PASM.. it is much easier to verify than actually testing for a True with all number combinations. That would be a huge waste of time.
I guess what I am saying is that learning Forth at this point in time, really is asking me to learn to practically apply PASM.
I can accept the burden of learning Spin and PASM, and even C along with Forth, I just don't want Go or other languages into my agenda. You can see it has already gotten very full.
YOU DON'T NEED TO KNOW ANYTHING ABOUT GO TO DO THINGS WITH PROPFORTH!!!!
Go is used to build, test, verify new kernels or if you want to build custom kernels. The only reason I did anything with Go was when Sal and Doug were testing the multi-channel stuff and wanted more input. That's it! I haven't touched Go in relation to PropForth for ANY OTHER REASON.
YOU DO NOT NEED TO KNOW ANYTHING ABOUT GO!
Testing TRUTH - let's try it:
Prop0 Cog6 ok
: tf-test-if dup if . ." is true" else . ." is false" then
." , agree?" cr ;
Prop0 Cog6 ok
0 tf-test-if
0 is false, agree?
Prop0 Cog6 ok
-1 tf-test-if
-1 is true, agree?
Prop0 Cog6 ok
1 tf-test-if
1 is true, agree?
Prop0 Cog6 ok
1) define a word to test for true (I got carried away in my test!):
: true-test if ." true" else ." false" then ;
2) put something on the stack and run your word:
0 true-test
-1 true-test
1 true-test
(you can keep going until you are comfortable)
3) sit back and marvel at your results and take comfort in the fact that you now know truth at least as far as if is concerned.
4) test other word sof truth in a similar fashion if you need to.
No Go, no Spin, no PASM, no wailing and gnashing of teeth, just try it and see and move on. I trust Sal an Doug's testing process enough to have faith they are consistent in the implementation of truth and anything else is a bug. Report a bug and it gets squashed in the next release, fix a bug and you've benefited the PropForth Community.
Regardless of the standard, it's what it actually does when asked that matters.
I've read that although Ruby (sorry to introduce another language, you don't need to know Ruby to use PropForth), has a written standard, folks that are making other Ruby implementations (JRuby, etc.) have to make their compiler do what the Ruby founder's does or the Ruby community won't except it.
Between the *.f files and the .spin kernel files, I go digging for answers when I get puzzled. If I were a good member of the community, I'd document each answer that I find.....I'm generally a bad citizen and don't document much.
I don't know about "bad citizen", more like "reasonable expectation citizen". Users have NO obligation to participate or contribute in any way, expect to be more or less business like and polite on occasion when asking questions. My begging and nagging for contributions rarely get results but has an occasional pay-off.
When you find tidbits that are interesting or unusual, if you mention it, we could make a page from your notes on the wiki. This would show that someone is investigating a topic, and might inspire Sal to expand the docs or support in that area. Right now he has little evidence that this effort is needed. Notice that when he DOES get evidence, he does a TON of work quickly, as when Marco and Poul asked about bits of assembler in the interpreter.
My point of view is very simple. If I am learning Forth, I'd prefer not having to include learning yet another language as part of the process of learning Forth.
Dude, I don't know very many more ways to express this. We agree with you. YOU DON'T NEED GO. Sal does. You are looking in Sal's tool box. Nobody's asking you to use Go. If you don't want to see any Go related material, rename it, delete it, don't look at it. Its not for you, its for Sal, he included it only as a courtesy to those that want to look at it.
Yes, I got the fact that I didn't have to use Go back in v5.0. And I hear what you are saying.
I pretty well have worked out all this questions I have had recently.
1. How I can get memory maps for PropForth
2. The true behavior or true/false
3. Where the missing source code went (Thanks Doug.)
4. How many languages I must actually know to learn Forth on the Propeller
My dilemma has been that from the start with Forth on the Propeller I approached from the point of view of a rank beginner.
I presumed that since Starting Forth was recommended by everyone that Forth could become a 'first language' for a Propeller user. Everything that has evolved indicates that it is not quite ready to take on that role. Though I do admit that I lean toward 'pfth' being more feasible for such a role.
Yes it is wonderful that people contribute such efforts to the Propeller for all of us to use. I do both admire and appreciate that. But there simply is a hazard of great undocumented works can only be appreciated by a few. And we all enjoy the Propeller's free software because sales of hardware are enough to afford free software.
The Arduinio took off like a rocket because the naive new user wasn't required to buy any software, and only had to learn what was presented as one simple language.
For the Propeller 2 to do well, I believe that the new user has to be willing to adopt it, not just us old timers. And it will be equally important that rank beginners feel that they have just one language to tangle with, not some of this, some of that, and maybe something else.
In sum, my concerns are about the future... not about old issues.
~~~~~~
For the PropForth.htm,
I started looking into how it could be improved and rapidly discovered two things. ...
1. Parts of it have yet to be finished. There are a lot of words that need to have explainations written that I am not sure how to proceed.
2. For the rank Beginner, it is just too fast paced. I would need to start over and write a completely different document to address more of the basics.
And so, I have backed off. One can't simply go from 'Starting Forth' into Forth on Propeller as the sort of information that would bridge the gap hasn't been written. And if I were to every write it, I have to do a lot more work at using all three Forths on Propeller, not just PropForth.
So I have felt overrun by Doug's feeling that I should take on the next phase of writing for PropForth along with following additions of Go language, MyGo, and the Little Stepper Project.
fl is one of those words that I am tangling with greatly.
I thought that I could create a project, pull it all together in a fastload file, set it in an Eeprom .f file and just load it at will.
But it becomes very obvious that what I think fl does and what is wants are two very different things.
It seems that it will take curly bracket comments without any trouble, but balks at / comments due to some sort of parsing issue.
It also seems that one needs to be sure to have the new words sequenced so that any new word does not refer to a yet to be defined word.
And one should investigate loading each word individually to debug specific word definition bugs before trying a global fast load.
So far I have spent more than a week on debugging a couple of fast load files. I feel the feature is an important asset to PropForth, so maybe a style sheet and a list of DO's and DON'Ts is appropriate. Please provide input of what you might be worthy of inclusion.
Comments
I think I have a pack of SR04's hiding someplace. If I find them, I can try hooking them up to a Quickstart and checking results.
PROPFORTH 6 - Multitasking?? Double cool!! Cooperative or preemptive? Multiprocessor multitasking is FUN!! Once you get things set up by a lead processor (COG), you can let the processors (COGs) go through the prioritized task tree and pick off he most appropriate thing for them to work on next. You create a lockable data structure for he work queue and a short piece of protected code to do the task selection and everybody starts humming away doing work. Back in my old Sperry days, we did this all the time. For a while, I worked on the dispatching code in the operating system. It was one of the coolest places to work in the operating system, I thought.
P2 should make this really confusing when you can have multi-COG, multitasking on multithreaded COGs!!
Thanks! Rick can be Beta tester 1. Sal wants feedback on how well it works (or not) and how to do it better. You insight on how these things work is the input he is seeking.
Sal's scheme is being tested on Prop 1, but is designed for Prop 2. Prop 2 will have 8 cogs times 4 threads per cog, so there will be 32 execution opportunities. Sal's scheme (so far) is simple: When an execution opportunity is finished, the task is transfered to the next available execution opportunity. All the threads are assigned to one of more "pools". The time critical tasks always jump to an available thread; the non time critical tasks wait until a thread is available. The developer just has to allocate sufficient threads to a pool to make it real time or background. If a thread goes down, we only loose 1/32 of processing ability. The overhead is minimal, so the multitasking shouldn't cost too much. But we'll get better numbers in beta test.
On Prop 1 there are only the eight threads (1 per cog) but it should be sufficient to see if it works and compare to non-multitasking PF5.5.
What is the right condition for a TRUE in PropForth, only -1 or any non-zero number? False is always Zero.
ANSI Forth is any non-zero number, but the only mention of TRUE in PropForth seems to be specifically a -1, except for Zero and Carry flag true conditions (which are a binary bit 1).
I think any non zero is true. Something about comparison for fuzzy logic, but we did not do anything with that yet.
The TRUE flag is -1 to be "most" true.
-1 is 'most' true
1 might be true, or any number other than zero may be true.
Please ask Sal and document the reality. Or do you want me to file a formal request in your Google site?
Of course, I could test all the code that uses t/f with all 32 bits of numbers, but that might take a bit of time.......................................................................................
OK, let me rephrase that. I am absolutely 100% positive that 0 is false and any non zero is not false, because I use this all the time.
This is how TRUE and FALSE are defined:
That is the extent Sal wanted to define it because:
There are lots of cases where the logic comes from a single bit, so we can NOT strictly say that -1 is true. So, in accordance with normal forth rules, zero is false, and everything else is derived from "zero or other". We can use any non zero value to be true if we want to be tricky, but generally we should not be tricky. It gets to be a grey area, which is why it works for fuzzy logic. There was not really a good way to make a definitive statement about the grey parts.
So -1 = TRUE. 0 = FALSE. Beyond that we are on our own. Unless you can sort out a good way to say this clearly.
Yes we are both sure that PropForth always has 0 = False.
I think I made the question quite clear. Either you don't know or do know.
A. True is limited to -1 only
B. True is any number other than Zero
This is not rocket science, and it certainly isn't 'fuzzy logic'. It is just something that is usually stated clearly in any Forth specification.
Can you give me a concise reference to where PropForth specifies that only -1 is True? Or a concise reference that any number other than 0 is accepted as True? Or, are you just shooting from the hip? All I can do is infer that that might be true.
Your quote that "-1, used frequently" just clouds the issue. When I test the following....
: test begin ." testing" cr 244 until ." out of loop " cr ;
I get behavior indicative of B, not A occurs at least some of the time.
This behavior is both standard Forth and useful.
Why assert that only -1 is acceptable? That certainly is not historically Forth. It just is confusing.
Your referance about the constant -1 just explains why the -1 constant was created... as a 'true indicator'. BUT it is one of many 'true indicators'. The .htm is full of omissions of topics that are quite important... very Beta.
I humbly suggest that this one gets resolved.
Can I chip in and fill you in on what is true and what is false
First off, any non-zero is accepted as a TRUE if it's involved in a conditional branch such as IF or UNTIL or WHILE. The reason that a -1 is preferred is when it comes to performing Boolean operations on true/false flags. Just imagine that you have two TRUE flags on the stack but one happens to be $20 and the other $01. Now if you try to AND two trues you should get a true except in this case you end up with a false because AND is a logical bitwise operation and does not know to perform a Boolean AND. The way around this is to convert non-Boolean flags to Boolean by a simple 0<> operation.
BTW, the analogous operation in PASM is the zero status, it's either zero or it's not zero which is fine to use for a branch condition but don't assume you can just perform logical operations to get a Boolean result.
I did grasp that -1 for True is useful in a specific context, but couldn't find what context or why.
I was looking for an answer to the actual behavior of PropForth as I am debugging some odd code behavior,.... not an interpretation of constant entries of the unfinished PropForth.htm document.
According to PB's interpretation of that text
"9.1.53 0
\ Word constant, 0 or false, used frequently"
might actually imply that there are more than one False condition as well.
After all, that would be much more consistent when you apply that there is more than one True condition to the following:
'9.1.46 -1
\ -1 or true, used frequently"
~~~~~~~~~~~
Some people love to march through version releases, others are very frugal. Beginners beware.
My sense of PropForth v5.5 is really a reasonable v0.95 in the real world. There is a lot that is right and useful -- even interesting, but it just isn't ready for the complete beginners.
Since it asserts its non-ANSI Forth status, it is often hard to know what is what as the author has never presented a rationale.... just a warning.
Having documentation clarify the non-ANSI Forth features would be a great aid. I wouldn't have to dig and guess. Less digging and guessing converts into more popularity. This stuff is daunting.
That is an excellent idea. Start writing it and we can review it, and fill in any missing bits.
Thanks Peter. Much better said than I.
Maybe ask the spcific question? "I'm doing this and see this, what is X?"
It might be easier to answer.
You are confusing two issues. The "used frequently" is the answer to "why define -1 as a constant when its already a number?" This is because the check for number happens LAST. Defining often used numbers as constants cuts down compile and build time significantly, at least enough for Sal to decide to add these entries to the dictionary.
All it needs is the documentation you are sorting out. I will post it as soon as you finish it.
Actually, it what you already know that gets in your way. You assume it does a stuff you expect from other environments, but it doesn't. Propforth just does what it says and the rest isn't defined. We can figure out what the undefined stuff does, but that doesn't necessarillly make it a requirement or fit any specification. We would have to make those decisions when we examine any given issue.
We're all looking forward to this clarification. I for one will review it and try to make useful comments when you post the draft, but much of this stuff is beyond me.
Most participants on these forums are experts on all aspects of technology, but remember, all I do is check that the stuff we say should be tested got tested, and what were the results. That is the full extent of my value-add.
@ Prof Braino
Please don't presume I am writing or editing documentation for the PropForth. I explained in December that I felt it was beyond my doing so for several reasons - physical limitations and intimate knowledge of PropForth.
These days, I see that V5.5 package removed much of the source code. I've no idea of how to keep up with all this. You removed the V5.0 that had all the reference material from the downloads.
I am just doing a little project to evaluate the status of V5.5 and to extend my knowledge a bit.
It is not going to happen. If you were Tom Sawyer, you'd just have to paint your own fence. Nice try.
Thanks for the info.
Geez. This again. Loopy in his mood. Please note
* ALL THE SOURCE IS INCLUDED IN THE DOWNLOAD, IT ALWAYS HAS. Please look in the misc directory, and find the my-goXXX.zip. This is the exact download as in 5.0, moved to a subdirectory to make it easier for new folk to find the burn and go kernels, as requested. The "hard" stuff is hidden here to keep it out of the way of new folks. But it is always included.
* The documentation is in the state its in for the exact reasons you state, we don't have time and nobody reads it anyway. Questions drive the documentation, demands less so.
* The stuff you ask for is already there. If you don't like it, fix it, or not. Simply complaining doesn't move it in any direction, I don't know what to change. Sorry, I'm just the receptionist.
It seemed to me that MyGo was just an added layer of distraction in the form of 'yet another social networking approach'. I don't have Twitter, I don't have Facebook, and for roaming internet I use a wifi link and a netbook.
http://www.go.com.mt/gomobile/services_mygobox.cfm
Maybe in your ReadMe.txt, you might explain what is both NEW and Necessary. This is just a suggestion.
My frustrations have been due to finding that PropForth seems to have so many places to look to find facts. And so many hard-to-decypher terms to interpret along the way.
At this point, I really don't want to be part of the PropForth developmental agenda, certainly don't want to be part of any promotional agenda... just trying to glean How To info from the user community. And I'd prefer not having to get involved with secondary promotions, like Google's MyGo... just to use something.
@Prof Braino
If I irk you, just let others provide answers to me. Please don't feel that every request for PropForth info is directed to you personally. LIve and let live.
You might take a look at how the Propeller Manual deals with "Logical Constants" for a clearer discussion of True as -1, and False as 0. Of course, the Forth community still asserts that False is always 0 and True is any number that is not 0. You might make mention of that as well. And if you desire to reach a broader audience, you are just going to have to teach more fundamentals. Experts are busy being experts and less curious unless there is a big benefit.
Good luck on your documentation.
Loopy, You DON'T have to learn or use Go, ITS JUST THE NAME OF THE ARCHIVE AND DIRECTORY WHERE THE SOURCE IS. Rename it if it displeases you.
So far, All your questions have been answered. 0 is FALSE; -1 is TRUE, non zero is also evaluated to true, but just be aware that true defined as -1. Simple, and typical for forth.
We only have a limited amount of resources, these are spent on essentials only. The rest is left to the folks that want those extras. You are free to ignore your own request.
* Without specific changes (add this paragraph on true, change this section to include this) I have no change to make.
* If you open an issue, at least we can track it and review options for any changes. If not, it gets lost.
* If you don't contribute the additional material and changes you demand, it might take a while.
* Responding to answers with a complaint instead of something constructive doesn't make it easier to give you what you want.
Propforth uses the ANS Forth standard which says, IF YOU CHOOSE to implement this word, this is how the standard defines it. The developer is free to make any deviation required.
Thanks! When I run out of extra work, this will be on the top off the list.
As stated, we use the ANSForth standard, and supplement this with Propfroth.htm for differences; these are due to the prop architecture. Between these we cover 90% of what folks ask. The remainder are addressed in a case by case basis, when and if they arise. So far the users have generated about 200 issues, and changes from these are rolled into subsequent releases as possible.
Remember the audience for these docs is estimated at about 20 people. And the last 10% tends to be the "tough" parts that people just don't get, any docs tend to make matters worse, one on one mentoring is most effective. How much more effort on docs would you think is reasonable?
I agree with Dave. Enough said.
Yes I've been grumpy as I tried to prepare a question that was of the form "Is it A behavior or B behavior?" and I got, a 'A because it is mostly true' and ' B might work if you want fuzzy logic.'
I am still confused about the roles of Go language and MyGo. I tend to feel that PropForth keeps moving ahead ambitiously without resolving presentation of some of the more fundamental topics.
In all fairness, I do have similar issues with TachyonForth, but it has had a much shorter existence. It is just hard to keep up with fast changing software in the earlier stages of development.
Dave's 'pfth' is the newest of the newcomers, but he has tried to dodge the paperchase of documentation by conforming to the ANSI Forth standard. That has seemed very prudent as there are several good texts and tutorials available on line for free.
I still love the idea of an excellent interpreted language for the Propeller, and I enjoy Forth.
I am just NOT comfortable with seeking out answers in PASM when I have no place else to go. But even that is changing. Unlike the original Propeller Tool, BST (Brad's Spin Tool) offers detailed and complete Compiler listings that will allow me to sort out actually memory maps on my own.
Ask a specific question and I can try to answer it. Make a statement, I can't help you much, as what's already been said covers it.
Remember this is a very powerful, professional tool, and I only know amature, beginner stuff. Maybe ask Peter or Nick directly if I can't answer clearly.
Also, some stuff just might be too "out there" for us to get with a lot of effort on our part. It might just take more time and experience before the light goes on. Happens to me all the time.
Go isn't any grand Google conspiracy to take over the programming world. It is an interesting implementation of a language oriented at system level programming. It has some interesting (and I think very nice) features that make it easier to program than C. Sal started playing with it when the experiments with Communicating Sequential Processes and multi-channel PC to Prop communication were going on. It has features that make this easy to implement and Sal used it to develop some tools. My understanding is that these tools stuck and made the build/test/verification process of PropForth releases easier. I like Go, it's very powerful on a PC but it has a large runtime footprint, so it is limited to being a PC/server language.
MyGO is simply the directory where all the Go code is put. When you install Go, you need to tell it a folder where it will find your source code and package modules and where in can put the binaries it creates. Sal and Doug started calling that MyGo on their PCs when they started playing. It's not a magic name that when found on a PC links it to Google central so it can dump it's brains to the mother cloud. It's just a name. On my Mac, I think the folder is just Go, on my PC, I forgot what I called it but it isn't MyGo. It's just like my folder "node" where my node.js code and packages go or workspace where eclipse puts my Java stuff. Just names, nothing else, nothing sinister.
When I get a new PropForth release, one of the first things I do is create a folder called sourcefiles at the top level of the package (.../v5.5/sourcefiles ) and then I find all the *.f files in anywhere in the package and copy them to this file. That way, no matter where something might be buried for building., testing or whatever, I have it in my sourcefiles so I can find it, refer to it, borrow snippets of code from it, etc. I also run my indexer against it so I can find word definitions within this folder.
Between the *.f files and the .spin kernel files, I go digging for answers when I get puzzled. If I were a good member of the community, I'd document each answer that I find.....I'm generally a bad citizen and don't document much.
Both Tachyon and PRopForth are tools of their creators. They follow the whims and needs of their creators and we're just along for the ride. They have decided to share their creations, since this a free donation of their time and passion, I feel they have no obligation to meet our demands for documentation or support. If I can benefit from their contribution through increased productivity or entertainment and mental stimulation, I'm that much richer. If I can't benefit, that's not their fault they don't owe that to me for the price I've paid. If either were a product I had purchased, then I would expect answers when asked and adequate documentation to answer most things I sought information on. As it is, I think Doug does a great job interfacing with Sal and being the visible face of PropForth on the forums. Peter has always been wonderfully helpful and responsive to Tachyon questions and problems and both camps are seriously moving their tools forward with interesting enhancements and features.
I seems obvious to me. Go may be handy, interesting, and powerful.... but all those things seem to offer even more distraction to me.
One can't know every language that comes into vogue. And some of us have different goals. For myself, Forth is appealing to peek and poke into the underlying Propeller architecture in an interactive mode. I've gotten into considering remote and mobile computing in the past, but find I have too many things going on in too many places.
My feelings are that Forth has a place in helping new users master what they can do with 8 Cogs... and that may be its greatest value.
Peter and Sal and Dave are all way ahead of me in terms of skills.
~~~~
BTW, regarding the fundamentals behind why zero = false, and all other numbers = true, it seems quite obvious in PASM that all the assembly words that test for any sort of Branch construction and any sort of Jump (that might be used as a Loop) are testing the Zero Flag. It can only see Zero and NOT Zero.
Since it is the most efficient code to do loops and branches, there is no reason to limit these to just a -1 =True. After all, there are many situations where one might want an Unsigned number to be True. And the number can be a Long, Word or Byte. The -1 True Constant might be to one size tied to the Forth Cell size.
Admittedly this is all speculation, but if I can read the PASM.. it is much easier to verify than actually testing for a True with all number combinations. That would be a huge waste of time.
I guess what I am saying is that learning Forth at this point in time, really is asking me to learn to practically apply PASM.
I can accept the burden of learning Spin and PASM, and even C along with Forth, I just don't want Go or other languages into my agenda. You can see it has already gotten very full.
Go is used to build, test, verify new kernels or if you want to build custom kernels. The only reason I did anything with Go was when Sal and Doug were testing the multi-channel stuff and wanted more input. That's it! I haven't touched Go in relation to PropForth for ANY OTHER REASON.
YOU DO NOT NEED TO KNOW ANYTHING ABOUT GO!
Testing TRUTH - let's try it:
1) define a word to test for true (I got carried away in my test!):
: true-test if ." true" else ." false" then ;
2) put something on the stack and run your word:
0 true-test
-1 true-test
1 true-test
(you can keep going until you are comfortable)
3) sit back and marvel at your results and take comfort in the fact that you now know truth at least as far as if is concerned.
4) test other word sof truth in a similar fashion if you need to.
No Go, no Spin, no PASM, no wailing and gnashing of teeth, just try it and see and move on. I trust Sal an Doug's testing process enough to have faith they are consistent in the implementation of truth and anything else is a bug. Report a bug and it gets squashed in the next release, fix a bug and you've benefited the PropForth Community.
Regardless of the standard, it's what it actually does when asked that matters.
I've read that although Ruby (sorry to introduce another language, you don't need to know Ruby to use PropForth), has a written standard, folks that are making other Ruby implementations (JRuby, etc.) have to make their compiler do what the Ruby founder's does or the Ruby community won't except it.
I don't know about "bad citizen", more like "reasonable expectation citizen". Users have NO obligation to participate or contribute in any way, expect to be more or less business like and polite on occasion when asking questions. My begging and nagging for contributions rarely get results but has an occasional pay-off.
When you find tidbits that are interesting or unusual, if you mention it, we could make a page from your notes on the wiki. This would show that someone is investigating a topic, and might inspire Sal to expand the docs or support in that area. Right now he has little evidence that this effort is needed. Notice that when he DOES get evidence, he does a TON of work quickly, as when Marco and Poul asked about bits of assembler in the interpreter.
Dude, I don't know very many more ways to express this. We agree with you. YOU DON'T NEED GO. Sal does. You are looking in Sal's tool box. Nobody's asking you to use Go. If you don't want to see any Go related material, rename it, delete it, don't look at it. Its not for you, its for Sal, he included it only as a courtesy to those that want to look at it.
I pretty well have worked out all this questions I have had recently.
1. How I can get memory maps for PropForth
2. The true behavior or true/false
3. Where the missing source code went (Thanks Doug.)
4. How many languages I must actually know to learn Forth on the Propeller
My dilemma has been that from the start with Forth on the Propeller I approached from the point of view of a rank beginner.
I presumed that since Starting Forth was recommended by everyone that Forth could become a 'first language' for a Propeller user. Everything that has evolved indicates that it is not quite ready to take on that role. Though I do admit that I lean toward 'pfth' being more feasible for such a role.
Yes it is wonderful that people contribute such efforts to the Propeller for all of us to use. I do both admire and appreciate that. But there simply is a hazard of great undocumented works can only be appreciated by a few. And we all enjoy the Propeller's free software because sales of hardware are enough to afford free software.
The Arduinio took off like a rocket because the naive new user wasn't required to buy any software, and only had to learn what was presented as one simple language.
For the Propeller 2 to do well, I believe that the new user has to be willing to adopt it, not just us old timers. And it will be equally important that rank beginners feel that they have just one language to tangle with, not some of this, some of that, and maybe something else.
In sum, my concerns are about the future... not about old issues.
~~~~~~
For the PropForth.htm,
I started looking into how it could be improved and rapidly discovered two things. ...
1. Parts of it have yet to be finished. There are a lot of words that need to have explainations written that I am not sure how to proceed.
2. For the rank Beginner, it is just too fast paced. I would need to start over and write a completely different document to address more of the basics.
And so, I have backed off. One can't simply go from 'Starting Forth' into Forth on Propeller as the sort of information that would bridge the gap hasn't been written. And if I were to every write it, I have to do a lot more work at using all three Forths on Propeller, not just PropForth.
So I have felt overrun by Doug's feeling that I should take on the next phase of writing for PropForth along with following additions of Go language, MyGo, and the Little Stepper Project.
fl is one of those words that I am tangling with greatly.
I thought that I could create a project, pull it all together in a fastload file, set it in an Eeprom .f file and just load it at will.
But it becomes very obvious that what I think fl does and what is wants are two very different things.
It seems that it will take curly bracket comments without any trouble, but balks at / comments due to some sort of parsing issue.
It also seems that one needs to be sure to have the new words sequenced so that any new word does not refer to a yet to be defined word.
And one should investigate loading each word individually to debug specific word definition bugs before trying a global fast load.
So far I have spent more than a week on debugging a couple of fast load files. I feel the feature is an important asset to PropForth, so maybe a style sheet and a list of DO's and DON'Ts is appropriate. Please provide input of what you might be worthy of inclusion.