Koehler, I think most of the forth-bashing is in response to the exagerated claims made by some Forth proponents. I am an experience C programmer, but I have done some C++ programming as well. I have always wondered about the amazing claims made by some of the Forth proponents. I felt that I needed to become proficient in programming in Forth before I could really judge whether the claims were justified or not. I've spent the last few months writing Forth code and Forth kernels, so at this point I believe I have enough experience to compare Forth with C. I stand by the comments that I made in my previous post.
I think everyone should learn how to program in Forth, but I believe Forth is not the best programming language for most applications. On the Prop, Spin, PASM, PropBasic or C are normally a better choice than Forth. I can go into more details about my reasons, but I think I have explained them in enough detail in previous posts.
Koehler, I think most of the forth-bashing is in response to the exagerated claims made by some Forth proponents. I am an experience C programmer, but I have done some C++ programming as well. I have always wondered about the amazing claims made by some of the Forth proponents. I felt that I needed to become proficient in programming in Forth before I could really judge whether the claims were justified or not. I've spent the last few months writing Forth code and Forth kernels, so at this point I believe I have enough experience to compare Forth with C. I stand by the comments that I made in my previous post.
I think everyone should learn how to program in Forth, but I believe Forth is not the best programming language for most applications. On the Prop, Spin, PASM, PropBasic or C are normally a better choice than Forth. I can go into more details about my reasons, but I think I have explained them in enough detail in previous posts.
Ok then, take my simple little wave player that reads directly from the SD card and plays the audio, so it doesn't use any buffers and only takes up 81 bytes of code, not including standard "libraries". Since Spin, PASM, PropBasic or C (lastly?) are normally a better choice than Forth, then please show me. I know it's not an FFT but this is something simple and practical.
BTW, this does not use an extra cog anywhere, just the same one that Tachyon runs the console from.
Peter, that's a nice little program. I've seen a few multi-cog versions of that in Spin/PASM. A single cog version should be doable in PASM, and it probably wouldn't use any hub RAM.
I think this could be done in a single cog using the COG memory model in C. We would need to implement the additional words that you don't show in your code. Could you post the source for those words also? BTW, to be fair you need to include the hub RAM used by all the words that you reference in your program. How many bytes do they use?
We would need to implement the additional words that you don't show in your code. Could you post the source for those words also?
Hi Dave
you only need the basic Tachyon.spin file and maybe EXTEND.fth (I haven't checked - but have the feeling you won't need it actually)
all the source is in there
looks a little different, because it is 'precompiled' - but is quite easy to read.
MJB
"Ok then, take my simple little wave player that reads directly from the SD card and plays the audio............"
Ok, I have no business commenting here as I have no Forth experience so I take a neutral stance but I couldn't help thinking if only you'd said....
.
"Ok then, take my simple little MP3 player that reads directly from the SD card and plays the audio...."
Ok, I have no business commenting here as I have no Forth experience so I take a neutral stance but I couldn't help thinking if only you'd said....
.
"Ok then, take my simple little MP3 player that reads directly from the SD card and plays the audio...."
I might be motivated to delve into Forth.
Dave H
This is just a quick hack to demonstrate speed and compact code size plus cog multi-use (that is, not requiring a separate cog). Now that I've had another look at it again I have whittled it down to 65 bytes.
As for MP3 even CPUs that have fast multiply instructions and large code space have difficulty with MP3 decoding so I haven't even seen MP3 decoding even in PASM on the Prop as it is limited in code memory and suffers from a lack of hardware multiply (and divide).
Comments
I think everyone should learn how to program in Forth, but I believe Forth is not the best programming language for most applications. On the Prop, Spin, PASM, PropBasic or C are normally a better choice than Forth. I can go into more details about my reasons, but I think I have explained them in enough detail in previous posts.
Ok then, take my simple little wave player that reads directly from the SD card and plays the audio, so it doesn't use any buffers and only takes up 81 bytes of code, not including standard "libraries". Since Spin, PASM, PropBasic or C (lastly?) are normally a better choice than Forth, then please show me. I know it's not an FFT but this is something simple and practical.
BTW, this does not use an extra cog anywhere, just the same one that Tachyon runs the console from.
I think this could be done in a single cog using the COG memory model in C. We would need to implement the additional words that you don't show in your code. Could you post the source for those words also? BTW, to be fair you need to include the hub RAM used by all the words that you reference in your program. How many bytes do they use?
you only need the basic Tachyon.spin file and maybe EXTEND.fth (I haven't checked - but have the feeling you won't need it actually)
all the source is in there
looks a little different, because it is 'precompiled' - but is quite easy to read.
MJB
Ok, I have no business commenting here as I have no Forth experience so I take a neutral stance but I couldn't help thinking if only you'd said....
.
"Ok then, take my simple little MP3 player that reads directly from the SD card and plays the audio...."
I might be motivated to delve into Forth.
Dave H
This is just a quick hack to demonstrate speed and compact code size plus cog multi-use (that is, not requiring a separate cog). Now that I've had another look at it again I have whittled it down to 65 bytes.
As for MP3 even CPUs that have fast multiply instructions and large code space have difficulty with MP3 decoding so I haven't even seen MP3 decoding even in PASM on the Prop as it is limited in code memory and suffers from a lack of hardware multiply (and divide).