Yes, the "two types of Forths" statement may be a gross exaggeration. However, it represents the two extremes of Forth implementations. Tachyon is clearly a machine Forth, and pfth is a standard Forth. It's harder to classify PropForth. It's not a standard Forth, but I don't think it's a machine Forth either. I see the pros and cons for each of the two extremes, but I don't understand an implementation that is neither standard nor particularly fast.
I'd have to say that PropForth is also 'machine Forth' as it has abandoned several features that are landmarks in ANS Forth. The DOES> is missing, the CREATE, the [ , and I am not exactly sure what else. But there is a definite paradigm shift of some sort. In fact, Peter was inspired to produce his more 'iconoclastic' TachyonForth from Sal's code, but he wanted to go faster and smaller.
At this point, one has to admit that a 1994 standard was unable to foresee all that has come to pass. So these explorations are extremely valid. There is AmForth for the ATmega and CamelForth for the 80c52 and other devices and these tend to hold closer to the ANS Forth 94. But they just can't quite do so within the space constraints. While they may be attractive to users of micro-controllers and Forth, I suspect that the Propeller just sizzles with speed when compared to them. Of course, Forth on the Propeller2 is going to offer even more of that. So machine Forth is pretty much here to stay.
You mentioned the ANS word WHILE as useful but not on the other Forths on the Propeller. I just happen to spend a bit of time comparing looping semantics in various Basic languages and there are more ways to describe a loop than necessary. If any Forth provides the ability to have a definite loop (one that counts a series of passes) and indefinite loops (one that continues until a test triggers an end), that is enough from a minimum stand point. The WHILE would use the indefinite loop.
So some reduction of ANS Forth 94 might just be that the lexicon has multiple ways of saying the same thing, and that tends to consume memory that can be used for words that are directed at a specific objective. I still haven't had time to do an in-depth study of ANS Forth lexicon, there are just too many things to be learned in the form of toom many topics. I am interested in the idea of a Reduced Lexicon subset of ANS Forth.
But I am sure that a lot of users will prefer ANS Forth as an entry point to learning Forth on the Propeller -- just because they can read more about Forth and that can help them envision what they hope to do with it.
Peter was inspired to produce his more 'iconoclastic' TachyonForth from Sal's code, but he wanted to go faster and smaller.
Not true, I didn't use Sal's code as a reference and it's absolutely nothing like it. I just did what I normally do, start with a clean slate and take it from there.
I understand exactly what Dave is saying when he says "machine Forth" and "standard Forth". The machine Forth may be non-standard but that is not what makes it a machine Forth. It's the coupling to the the machine itself and leveraging the unique capabilities of that machine that makes it a machine Forth. After all I could very easily write a completely standard ANS Forth that runs on top of Tachyon, but the ANS Forth would definitely not be machine Forth.
Okay, I must shut up and study more. But I do seem to notice some similarities... such as no DOES> , no [ , and such. And it is evident that you created the decompiler for Propforth. So it seems that it has had a bit of influence on Tacnyon.
Okay, I must shut up and study more. But I do seem to notice some similarities... such as no DOES> , no [ , and such. And it is evident that you created the decompiler for Propforth. So it seems that it has had a bit of influence on Tacnyon.
Because PF source is not really one document but must be run through spinmaker plus a lot of the assembler words were base-64 encoded it made it all hard to follow. I wanted to make some changes plus what really motivated me to delve into it was why it was so slow, even slower than Spin. So I wrote an enhanced decompiler that restored the code back to source code form (not just a listing) including all the BEGIN and THENs etc including indentation that are inferred in the code but not actually there.
Not having the same words may also be for the same reasons which may have more to do with the Propeller and embedded uses rather than "copying".
Well, I guess I need to form a question of sorts. The focus is on 'word creation'
More traditional Forth versions have 4 methods.
a. create
b. : .... ;
c. variable
d. constant
Both Tachyon and PropForth abandoned the 'create' which seems to have originally been the word that can actually provided the other 3.
I realize that Tachyon does some rather new things, such as directly compiles words as they arrive from the keyboard and provides loops and branches in the interpreter.
But what I trying to find out is whether there was a shift toward abandoning create and the related does> by many people or is this something that is new to Propeller Forths in order to gain speed or compact code.
In PropForth, the construction of an array has migrated over to the use of {variable allot ....} and that makes perfect sense to me as arrays are all about variables. But I've yet to fully understand why { create ... does> ... } was abandoned by both of you along with several other words that seem mainly useful along with the {create ... does>... }.
It seems you have found that portion of Moore's Forth to be not appropriate to the Propeller. I presume that the { : ... ; } either provides everything that create did, or that this aspect of word creation has been abandoned. But I am not sure which is true.
Hi Loopy,
regarding TACHYON this is not correct.
If you take the time to search TACHYON V2.1.spin for 'create'
you will find a lot of create.
Create is the base for many of the other creating words.
AND it is even vectored.
So if s.o. wants he can easily create a special create and use this instead of the built in create word.
Peter did not do it yet - but maybe there is a way to implement a DOES> ...
I don't know how to do it yet.
@MJB
thanks. I will take another look at what I did for comparisons between Starting Forth and Tachyon. I may have used an older version that didn't list create. Or done something very stupid and labled a comparison of Starting Forth and PropForth as belonging to Tachyon.
I am trying to catch up with some items that never quite got answered for me. So I am working again with older and more traditional Forth to try to understand what are the differences that are really there in Forth on the Propeller. I just might be that the 3 forms of word creation work fine without having { create } and [ does> }
This is incorrect. As with Tachyon, propforth didn't abandon create either. create just works differently in propforth, due to the way the prop works, and the way the dictionary was implemented. This was not an arbitrary decision, it was based on the ramifications of the prop architecture.
If you see nick lordi's post in the other thread you can see an example of it used correctly in propforth. The use of create got a little more involved to make everything else easier, smaller and faster. Simply the result of that decision.
@MJB
thanks. I will take another look at what I did for comparisons between Starting Forth and Tachyon. I may have used an older version that didn't list create. Or done something very stupid and labled a comparison of Starting Forth and PropForth as belonging to Tachyon.
I am trying to catch up with some items that never quite got answered for me. So I am working again with older and more traditional Forth to try to understand what are the differences that are really there in Forth on the Propeller. I just might be that the 3 forms of word creation work fine without having { create } and [ does> }
ok - here the TACHYON places where CREATE is defined and used
CREATEWORD is the actual workhorse do do the dictionary creation
' CREATE <name> - Create a name in the dictionary and also a code entry
CREATE byte REG,createvec,WFETCH,QDUP,_IF,01,AJMP ' execute extended or user defined CREATE?
byte XCALL,xCREATEWORD '
byte _BYTE,VARB,XCALL,xBCOMP,_0 ' set default bytecode as a VARIABLE
' Create a new entry in the dictionary and also in the XCALLS table but also prevent any execution of code
' at an <enter> which would otherwise normally occur.
' unsmudge any previous name in case this is a fall-through.
' : <name>
COLON byte XCALL,xATSMUDGE,CLR ' unsmudge any previous definition
byte XCALL,[B]xCREATE[/B] ' this forms an XCALL,index to this new definition
byte XCALL,xATSMUDGE,SET
byte MINUS1,XCALL,xALLOT
byte _BYTE,defining,REG,flags,SET,EXIT
' byte aligned variable
CVARIABLE byte _BYTE,",",REG,delim,CSTORE
byte XCALL,[B]xCREATE[/B],_1,XCALL,xALLOT
byte REG,delim+1,CFETCH,_BYTE,",",EQ,ZEQ,_UNTIL,@cva01-@CVARIABLE
cva01 byte BL,REG,delim,CSTORE,EXIT
' word aligned variable
WVARIABLE byte _BYTE,",",REG,delim,CSTORE
byte REG,codes,WFETCH,_1,_ANDN,INC,REG,codes,WSTORE ' align to a byte before a long address
byte XCALL,[B]xCREATE[/B],_2,XCALL,xALLOT
byte REG,delim+1,CFETCH,_BYTE,",",EQ,ZEQ,_UNTIL,@wva01-@WVARIABLE
wva01 byte BL,REG,delim,CSTORE,EXIT
' long aligned variable
VARIABLE byte _BYTE,",",REG,delim,CSTORE
byte REG,codes,WFETCH,_3,_ANDN,_3,PLUS,REG,codes,WSTORE ' align to a byte before a long address
byte XCALL,[B]xCREATE[/B],_4,XCALL,xALLOT
byte REG,delim+1,CFETCH,_BYTE,",",EQ,ZEQ,_UNTIL,@va01-@VARIABLE
va01 byte BL,REG,delim,CSTORE,EXIT
' long aligned table - no memory allocated
TABLE byte REG,codes,WFETCH,_3,_ANDN,_3,PLUS,REG,codes,WSTORE ' align to a byte before a long address
byte XCALL,[B]xCREATE[/B],EXIT
ACONSTANT
byte XCALL,xEXECUTENOW ' process literal
cn01 byte REG,codes,WFETCH,_3,_ANDN,_3,PLUS,REG,codes,WSTORE ' align to a byte before a long address
byte XCALL,[B]xCREATE[/B],MINUS1,XCALL,xALLOT ' create and step back to override VARB
byte _BYTE,CONL,XCALL,xBCOMP ' compile a CONL instead
byte REG,codes,WFETCH,INC,STORE
byte _4,XCALL,xALLOT,EXIT
Not to interrupt this fun discussion but was a winner announced for the "Forth of the Forth" challenge?
Hi David, the week flies by so fast and I'm like that court jester juggling all these objects. There's the P2 documentation project, there's the P2 development on the FPGA, there's my QVGA display I'm working on, and besides all the other stuff I do some real work But the 7 days are fast approaching, hang tight.
This challenge has had a good and unexpected response and as I mentioned I just need to announce some winners. Well that will be soon but just letting you know that should be in the next 24 hours as I'm stuck out west here in Goondiwindi. Nah, that's not pronounced "goon di" but "gun da" and "windy" or Gundy for short where all the men better wear hats or at least a cap, usually from some local farming equipment or engineering works and everyone drives big 4WDs with extra spot lights mounted on the bull bars and a bigger set up behind the cab for piggin'. Yep, so please bear with me as I find some time to sift through these entries and announce the winners.
Another Ozzie has gone over to Dreamtime...........
We can be patient until you come back. I am not even sure my entry really qualifies as a completed project.
Christmas is coming... we all want to slip away for some fun.
Dang it! Wouldn't 't you know my other contest idea was a Parallax Piggin' hat with lights controlled by a Propeller driven wind power management system! Sounds like that would have come in handy out there in Gundy!!
Comments
At this point, one has to admit that a 1994 standard was unable to foresee all that has come to pass. So these explorations are extremely valid. There is AmForth for the ATmega and CamelForth for the 80c52 and other devices and these tend to hold closer to the ANS Forth 94. But they just can't quite do so within the space constraints. While they may be attractive to users of micro-controllers and Forth, I suspect that the Propeller just sizzles with speed when compared to them. Of course, Forth on the Propeller2 is going to offer even more of that. So machine Forth is pretty much here to stay.
You mentioned the ANS word WHILE as useful but not on the other Forths on the Propeller. I just happen to spend a bit of time comparing looping semantics in various Basic languages and there are more ways to describe a loop than necessary. If any Forth provides the ability to have a definite loop (one that counts a series of passes) and indefinite loops (one that continues until a test triggers an end), that is enough from a minimum stand point. The WHILE would use the indefinite loop.
So some reduction of ANS Forth 94 might just be that the lexicon has multiple ways of saying the same thing, and that tends to consume memory that can be used for words that are directed at a specific objective. I still haven't had time to do an in-depth study of ANS Forth lexicon, there are just too many things to be learned in the form of toom many topics. I am interested in the idea of a Reduced Lexicon subset of ANS Forth.
But I am sure that a lot of users will prefer ANS Forth as an entry point to learning Forth on the Propeller -- just because they can read more about Forth and that can help them envision what they hope to do with it.
Not true, I didn't use Sal's code as a reference and it's absolutely nothing like it. I just did what I normally do, start with a clean slate and take it from there.
I understand exactly what Dave is saying when he says "machine Forth" and "standard Forth". The machine Forth may be non-standard but that is not what makes it a machine Forth. It's the coupling to the the machine itself and leveraging the unique capabilities of that machine that makes it a machine Forth. After all I could very easily write a completely standard ANS Forth that runs on top of Tachyon, but the ANS Forth would definitely not be machine Forth.
BTW, WHILE is too useful a word not to have.
Not having the same words may also be for the same reasons which may have more to do with the Propeller and embedded uses rather than "copying".
More traditional Forth versions have 4 methods.
a. create
b. : .... ;
c. variable
d. constant
Both Tachyon and PropForth abandoned the 'create' which seems to have originally been the word that can actually provided the other 3.
I realize that Tachyon does some rather new things, such as directly compiles words as they arrive from the keyboard and provides loops and branches in the interpreter.
But what I trying to find out is whether there was a shift toward abandoning create and the related does> by many people or is this something that is new to Propeller Forths in order to gain speed or compact code.
In PropForth, the construction of an array has migrated over to the use of {variable allot ....} and that makes perfect sense to me as arrays are all about variables. But I've yet to fully understand why { create ... does> ... } was abandoned by both of you along with several other words that seem mainly useful along with the {create ... does>... }.
It seems you have found that portion of Moore's Forth to be not appropriate to the Propeller. I presume that the { : ... ; } either provides everything that create did, or that this aspect of word creation has been abandoned. But I am not sure which is true.
regarding TACHYON this is not correct.
If you take the time to search TACHYON V2.1.spin for 'create'
you will find a lot of create.
Create is the base for many of the other creating words.
AND it is even vectored.
So if s.o. wants he can easily create a special create and use this instead of the built in create word.
Peter did not do it yet - but maybe there is a way to implement a DOES> ...
I don't know how to do it yet.
thanks. I will take another look at what I did for comparisons between Starting Forth and Tachyon. I may have used an older version that didn't list create. Or done something very stupid and labled a comparison of Starting Forth and PropForth as belonging to Tachyon.
I am trying to catch up with some items that never quite got answered for me. So I am working again with older and more traditional Forth to try to understand what are the differences that are really there in Forth on the Propeller. I just might be that the 3 forms of word creation work fine without having { create } and [ does> }
This is incorrect. As with Tachyon, propforth didn't abandon create either. create just works differently in propforth, due to the way the prop works, and the way the dictionary was implemented. This was not an arbitrary decision, it was based on the ramifications of the prop architecture.
If you see nick lordi's post in the other thread you can see an example of it used correctly in propforth. The use of create got a little more involved to make everything else easier, smaller and faster. Simply the result of that decision.
CREATEWORD is the actual workhorse do do the dictionary creation
' CREATE <name> - Create a name in the dictionary and also a code entry CREATE byte REG,createvec,WFETCH,QDUP,_IF,01,AJMP ' execute extended or user defined CREATE? byte XCALL,xCREATEWORD ' byte _BYTE,VARB,XCALL,xBCOMP,_0 ' set default bytecode as a VARIABLE ' Create a new entry in the dictionary and also in the XCALLS table but also prevent any execution of code ' at an <enter> which would otherwise normally occur. ' unsmudge any previous name in case this is a fall-through. ' : <name> COLON byte XCALL,xATSMUDGE,CLR ' unsmudge any previous definition byte XCALL,[B]xCREATE[/B] ' this forms an XCALL,index to this new definition byte XCALL,xATSMUDGE,SET byte MINUS1,XCALL,xALLOT byte _BYTE,defining,REG,flags,SET,EXIT ' byte aligned variable CVARIABLE byte _BYTE,",",REG,delim,CSTORE byte XCALL,[B]xCREATE[/B],_1,XCALL,xALLOT byte REG,delim+1,CFETCH,_BYTE,",",EQ,ZEQ,_UNTIL,@cva01-@CVARIABLE cva01 byte BL,REG,delim,CSTORE,EXIT ' word aligned variable WVARIABLE byte _BYTE,",",REG,delim,CSTORE byte REG,codes,WFETCH,_1,_ANDN,INC,REG,codes,WSTORE ' align to a byte before a long address byte XCALL,[B]xCREATE[/B],_2,XCALL,xALLOT byte REG,delim+1,CFETCH,_BYTE,",",EQ,ZEQ,_UNTIL,@wva01-@WVARIABLE wva01 byte BL,REG,delim,CSTORE,EXIT ' long aligned variable VARIABLE byte _BYTE,",",REG,delim,CSTORE byte REG,codes,WFETCH,_3,_ANDN,_3,PLUS,REG,codes,WSTORE ' align to a byte before a long address byte XCALL,[B]xCREATE[/B],_4,XCALL,xALLOT byte REG,delim+1,CFETCH,_BYTE,",",EQ,ZEQ,_UNTIL,@va01-@VARIABLE va01 byte BL,REG,delim,CSTORE,EXIT ' long aligned table - no memory allocated TABLE byte REG,codes,WFETCH,_3,_ANDN,_3,PLUS,REG,codes,WSTORE ' align to a byte before a long address byte XCALL,[B]xCREATE[/B],EXIT ACONSTANT byte XCALL,xEXECUTENOW ' process literal cn01 byte REG,codes,WFETCH,_3,_ANDN,_3,PLUS,REG,codes,WSTORE ' align to a byte before a long address byte XCALL,[B]xCREATE[/B],MINUS1,XCALL,xALLOT ' create and step back to override VARB byte _BYTE,CONL,XCALL,xBCOMP ' compile a CONL instead byte REG,codes,WFETCH,INC,STORE byte _4,XCALL,xALLOT,EXITHi David, the week flies by so fast and I'm like that court jester juggling all these objects. There's the P2 documentation project, there's the P2 development on the FPGA, there's my QVGA display I'm working on, and besides all the other stuff I do some real work
We can be patient until you come back. I am not even sure my entry really qualifies as a completed project.
Christmas is coming... we all want to slip away for some fun.