Tweaking something is not the same as writing it over from scratch which is what you'd pretty much have to do if you tried to move a program written for PropForth to Tachyon or pfth and you'd certainly have to do that for a program written in Spin if you wanted to move it anywhere including to P2.
Edit: Sorry, Spin code would not have to be rewritten from scratch to move from P1 to P2 but it would have to be "tweaked".
Appearantly portability is subjective, and forth is little different from any other language, in that one must adjust the code or the HAL when moving from place to place. In the case of forth, the operators like + re always completely portable, and the hardware specific custom functions are never completely portable. The remaining functions lie somwhere in between these two extremes.
If another language is "more portable" it is due to the more comprehensive HAL, which forth tends to omit due to the very constraints that made forth the tool of choice in the first place.
None of this matters, really. When using forth on the prop, you only need to worry about forth on the prop. If you are working on the prop, are you really going to port a prop application to an arduino? Forth, or C, or SPIN, or other? If it runs on a single threaded processor, was it really a real prop application?
In the case of forth, the operators like + re always completely portable, and the hardware specific custom functions are never completely portable. The remaining functions lie somwhere in between these two extremes.
Interesting. Are language features such as IF/THEN/ELSE, looping, function (word) definition and invocation, stack manipulation, etc the same in all of the Propeller Forths? That would certainly make moving from one to the other easier. If it is only the words that interface to the hardware that are different then I guess Forth code is more portable than I thought.
Interesting. Are language features such as IF/THEN/ELSE, looping, function (word) definition and invocation, stack manipulation, etc the same in all of the Propeller Forths? That would certainly make moving from one to the other easier. If it is only the words that interface to the hardware that are different then I guess Forth code is more portable than I thought.
You'd have to to ask Dave and Peter about that, I only work with the one project. But it they implemented those words according to the standard (and you can bet Dave did) then those words will work the same. The non standard stuff, like the special register SPIN/PASM words may or may not be the same, as there is no standard. In propforths case, we could not deicde the best default cell size (long fof COG memory, word for hub memory, or character for old times sake) so we made each size explicite with no default. But that was an engineering call, one could make acase for the other three options.
Thing is, the stuff I did on the PC in forth is not stuff to be done on the prop, and vice versa. Unless you include any arbitrary examples, protability as discussed is not so relevant for microcontrollers with limited resources, as implementing it doesn't have much benefit if any.
Actually, the + operator does not work the same on all Forths. There is no constraint on the cell size or the number of bits used in performing operations. It is doubtful that even a trivial piece of Forth code will run the same on the 3 different Prop Forths. The different Forth interpreters treat many "standard" Forth words differently.
Actually, the + operator does not work the same on all Forths. There is no constraint on the cell size or the number of bits used in performing operations. It is doubtful that even a trivial piece of Forth code will run the same on the 3 different Prop Forths. The different Forth interpreters treat many "standard" Forth words differently.
Incorrect. plus uses two stack items, regardless of the stack element size.
If we run the word + from any forth command line, will it not consume the first two items on the stack and leave the result? If not , the plus was implemented incorrectly. If so, then its portable.
Your are correct that any function that allocates specific memory needs to be checked, but the standrad words must be portable, or they are wrong.
...portability as discussed is not so relevant for microcontrollers...
I would say it's essential.
Many times I have developed a controller application, or parts of one, on a PC. I just wrap the code in some thin simulation of the interfaces it needs on the target.
That way it is much easier to edit, build, run the code and debug what is going on if need be. Then you can also build unit tests that exercise modules of you application.
When it all looks good then it can be loaded to the target and run for real.
This style of development saves a ton of time and allows software development to proceed before the hardware is even built. It depends on having portable code.
Back to that FFT. If I had to write my first ever FFT from scratch on the Propeller or some other micro it may never have been finished.
Incorrect. plus uses two stack items, regardless of the stack element size.
If we run the word + from any forth command line, will it not consume the first two items on the stack and leave the result? If not , the plus was implemented incorrectly. If so, then its portable.
Your are correct that any function that allocates specific memory needs to be checked, but the standrad words must be portable, or they are wrong.
So you're saying that the + operator will produce the same result on a 16-bit Forth versus a 32-bit Forth. I don't think so.
One of the fundamental Forth words is CREATE. However, PropForth implements this in a non-standard way. Are you saying that PropForth is wrong?
Many times I have developed a controller application, or parts of one, on a PC. I just wrap the code in some thin simulation of the interfaces it needs on the target.
That way it is much easier to edit, build, run the code and debug what is going on if need be. Then you can also build unit tests that exercise modules of you application.
When it all looks good then it can be loaded to the target and run for real.
This style of development saves a ton of time and allows software development to proceed before the hardware is even built. It depends on having portable code.
Back to that FFT. If I had to write my first ever FFT from scratch on the Propeller or some other micro it may never have been finished.
While this is all true I think that the counter argument is that Forth is an interactive language so it makes writing the code on the target device a lot easier because you can use the target as the debug platform in a more straight forward way. Of course, this could be said for any interactive language especially ones with an immediate mode where you don't have to type in an entire program and type "run", you just have to enter a single statement and have it evaluated. This I think was pioneered by Lisp but is certainly present in modern languages like Python and Ruby as well as in some implements of Javascript. It isn't the exclusive domain of Forth although it might be at the present on the Propeller 1.
One of the nicest features of Forth is that it implements a compiler in a very small amount of code, and the compiler runs very fast. pfth can compile hundreds of lines of Forth code in just a few seconds on the Prop. A limited Spin compiler that I run under Spinix takes minutes to compile a similar amount of Spin code. So Forth is nice for cases where development needs to be done on the target processor. However, in cases where development can be done on a workstation that can compile code in a few seconds, I think a language such as C is a better choice.
I believe that the same is true of Catalina C. Ross once told me that he ported my XLISP language to the Propeller using Catalina and it's a pretty large program. I wonder how much effort would be required to port the Catalina C compiler itself? :-)
Good point - I haven't tried compiling Catalina with itself for a while. There didn't seem much point since we didn't (at the time) have a proper Spin compiler that could run on the Propeller - but with OpenSpin, we now do!
Has anyone tried compiling OpenSpin using PropGCC?
So you're saying that the + operator will produce the same result on a 16-bit Forth versus a 32-bit Forth. I don't think so.
Until the result is greater than 16 bit the result would be the same. Above 16 bit its a hardware limitation. adding 2 and 4 will produce the same result on both.
One of the fundamental Forth words is CREATE. However, PropForth implements this in a non-standard way. Are you saying that PropForth is wrong?
I'm saying Propforth does not implement create according to the standard, as stated (a couple times now, I think). Propforth implements create according to the constraints of the prop and the design of the kernel.
The standard words that are implemented according to the standard all take the save inputs and produce the same results. All nonstandard words, due to hardware limitations, application or other constraints, do what ever, according to the requirements. As explained in the standard.
Sorry, I keep getting this thread confused with another thread that is talk about forth. I'll tone it down on this thread.
Comments
Appearantly portability is subjective, and forth is little different from any other language, in that one must adjust the code or the HAL when moving from place to place. In the case of forth, the operators like + re always completely portable, and the hardware specific custom functions are never completely portable. The remaining functions lie somwhere in between these two extremes.
If another language is "more portable" it is due to the more comprehensive HAL, which forth tends to omit due to the very constraints that made forth the tool of choice in the first place.
None of this matters, really. When using forth on the prop, you only need to worry about forth on the prop. If you are working on the prop, are you really going to port a prop application to an arduino? Forth, or C, or SPIN, or other? If it runs on a single threaded processor, was it really a real prop application?
You'd have to to ask Dave and Peter about that, I only work with the one project. But it they implemented those words according to the standard (and you can bet Dave did) then those words will work the same. The non standard stuff, like the special register SPIN/PASM words may or may not be the same, as there is no standard. In propforths case, we could not deicde the best default cell size (long fof COG memory, word for hub memory, or character for old times sake) so we made each size explicite with no default. But that was an engineering call, one could make acase for the other three options.
Thing is, the stuff I did on the PC in forth is not stuff to be done on the prop, and vice versa. Unless you include any arbitrary examples, protability as discussed is not so relevant for microcontrollers with limited resources, as implementing it doesn't have much benefit if any.
Incorrect. plus uses two stack items, regardless of the stack element size.
If we run the word + from any forth command line, will it not consume the first two items on the stack and leave the result? If not , the plus was implemented incorrectly. If so, then its portable.
Your are correct that any function that allocates specific memory needs to be checked, but the standrad words must be portable, or they are wrong.
Many times I have developed a controller application, or parts of one, on a PC. I just wrap the code in some thin simulation of the interfaces it needs on the target.
That way it is much easier to edit, build, run the code and debug what is going on if need be. Then you can also build unit tests that exercise modules of you application.
When it all looks good then it can be loaded to the target and run for real.
This style of development saves a ton of time and allows software development to proceed before the hardware is even built. It depends on having portable code.
Back to that FFT. If I had to write my first ever FFT from scratch on the Propeller or some other micro it may never have been finished.
One of the fundamental Forth words is CREATE. However, PropForth implements this in a non-standard way. Are you saying that PropForth is wrong?
Good point - I haven't tried compiling Catalina with itself for a while. There didn't seem much point since we didn't (at the time) have a proper Spin compiler that could run on the Propeller - but with OpenSpin, we now do!
Has anyone tried compiling OpenSpin using PropGCC?
Ross.
Your wish is my command:
Openspin compiles easily with propgcc. Only issue is that propgcc libs lack a realpath() function. I just commented that out for this experiment.
Now to figure out how to get a SD and file system on my GG board with its 32MB RAM. So I can test this.
Cool! I'll try self-compiling Catalina again!
Ross.
Until the result is greater than 16 bit the result would be the same. Above 16 bit its a hardware limitation. adding 2 and 4 will produce the same result on both.
I'm saying Propforth does not implement create according to the standard, as stated (a couple times now, I think). Propforth implements create according to the constraints of the prop and the design of the kernel.
The standard words that are implemented according to the standard all take the save inputs and produce the same results. All nonstandard words, due to hardware limitations, application or other constraints, do what ever, according to the requirements. As explained in the standard.
Sorry, I keep getting this thread confused with another thread that is talk about forth. I'll tone it down on this thread.