It seems like one of the big advantages you get having an explicit stack in Forth is the ability for a "word" to return more than one result. That isn't easy with a language like C since functions have only a single return value. You end up having to resort to reference parameters or pointers to return more than one value. How often does Forth code take advantage of the ability for a word to return multiple values?
I've definitely used that, and it's a specific case of a more general benefit of Forth.
In C a function call involves a prologue of pushing arguments onto the stack, making the call, pushing the return, and finally the epilogueof popping the arguments. It's a bit of a production which makes function calls more expensive than inline code. Although many modern C compilers will use register linkage if a function is small and doesn't call another function.
In Forth you are always working with the stack, so there's much less of a penalty when calling another function (word in Forth semantics), particularly when that function consumes the input arguments as this saves the cost of the function epilogue. This does encourage breaking code into smaller chunks and reusing those chunks, hence the smaller size.
Well, PropGCC always passes arguments in registers as long as there aren't too many. I think it can handle at least 4 or 5. However, you're right that registers get saved sometimes for nested calls. However, Forth always requires every argument to be on the stack. One thing that I think makes Forth so fast is that programmers basically hand-optimize their code to avoid lots of stack manipulation. In any case, I'm a fan of Forth. There is something really appealing about a language design that gets so much power out of so few simple concepts. I like Lisp for the same reason.
Indeed. I've got an industrial project (road sign controller) in front of me and keep thinking -- based on what Peter has demonstrated -- that Tachyon would be a good choice for it. Time to start cracking, I guess!
It's been a while since I've played with Forth, but I always found it a bit tedious having to keep track of where things are on the stack. I also missed having syntax checking and other things that a good compiler provides. The interactive nature of Forth is nice, but it's not the way I program. So it seems to come down to a matter of preference on how people like to program. I enjoy using a compiler with lots of error checking, library support and code optimization. Other people prefer Forth.
Another thing that bothers me about Forth is the lack of arrays and data structure. These can be created using the DOES> word, but some Forths don't support this word. Arrays and data structures can be implemented without DOES>, but it's takes more cycles to do it. Even with DOES>, accessing arrays and structures is less efficient in Forth than it is in other languages.
And then there is the non-adherence to standards and the lack of portability. I understand that Forth is less efficient when it tries to adhere to a standard, so it's understandable that there are so many variants of Forth. Other languages are able to maintain strict adherence to standards while at the same time they generate code is quite efficient. The use of standards allows development on other machine, and makes porting to the target machine easier. As an example, I can develop C code on almost any platform and thoroughly test it before I even try it on a Prop. And in most cases I can then run the code on the Prop without making a single change in the source code.
It's been a while since I've played with Forth, but I always found it a bit tedious having to keep track of where things are on the stack. I also missed having syntax checking and other things that a good compiler provides. The interactive nature of Forth is nice, but it's not the way I program. So it seems to come down to a matter of preference on how people like to program. I enjoy using a compiler with lots of error checking, library support and code optimization. Other people prefer Forth.
Another thing that bothers me about Forth is the lack of arrays and data structure. These can be created using the DOES> word, but some Forths don't support this word. Arrays and data structures can be implemented without DOES>, but it's takes more cycles to do it. Even with DOES>, accessing arrays and structures is less efficient in Forth than it is in other languages.
And then there is the non-adherence to standards and the lack of portability. I understand that Forth is less efficient when it tries to adhere to a standard, so it's understandable that there are so many variants of Forth. Other languages are able to maintain strict adherence to standards while at the same time they generate code is quite efficient. The use of standards allows development on other machine, and makes porting to the target machine easier. As an example, I can develop C code on almost any platform and thoroughly test it before I even try it on a Prop. And in most cases I can then run the code on the Prop without making a single change in the source code.
I can't stand C's pointers, never have, never will. The syntax is absolutely awful.
I don't plan on porting my saturated vapor pressure equations using F32 / Tachyon written for a Propeller 1 to the nearest PDP-11 Dave. We are not talking mainframes here but specialized microprocessors and P1 has already blown the mold. I've been able to accomplish everything I need with TABLES, don't plan on writing a web server on Tachyon ( oh wait there is one) or an FTP server (whoops that's done too) or Telnet (oh gosh how is this all done without formal structures and arrays).
Yes well I'm not sorry for the snark, you mentioned you like compilers checking your work earlier, well when I break out my paints and canvass I don't need a line drawing on the page, with great freedom comes responsibility. Tachyon assumes your are a professional if you are gonna release a professional product base on the the "system". Also if you do proper functional decomposition and test the little WORDS as you go then the compiler's precious bounds checking et al is moot. This is great when I have a new chip without a driver and need few quick words to get at its guts. The last driver I wrote the other day was for this cool chip:
MAX31856 universal type Thermocouple-to-digital converter
Measures full range for B, E, J, K, N, R, S and T thermocouple types
19-bit SPI interface
AND I AM A NOVICE forth programmer but I am a digital god behind a Tachyon console, at least in my mind.
Anyway, some like C some don't. I like Tachyon/P1 as a complete system (not just a language and compiler) that is out of this world extensible.
Have a great day and I do mean this, you are a very talented person as can be seen by your great contributions to P1.
Indeed. I've got an industrial project (road sign controller) in front of me and keep thinking -- based on what Peter has demonstrated -- that Tachyon would be a good choice for it. Time to start cracking, I guess!
The link to one of your projects is very impressive Peter.
As I have said before Peter, I am truly amazed at what you have achieved!
Go JonnyMac!
Push up any question you have maybe in the Tachyon thread. I can help you over the "getting started" phase (build, backup, modules, autorun and basics) Then Peter, MJB and others can help you with how to crack the problem (decompose) into Forth Words ( little routines) that you string the program together with in the language terms of the problem domain. Peter is very clever here with this part.
It can be really fun but it's completely different from any other language methodology which can cause some brain pain. Brain pain is good for you.
I can't stand C's pointers, never have, never will. The syntax is absolutely awful.
Yes, I think the use of "->" is unfortunate. I don't see why "." can't be used for either direct structure field references or through a pointer. They seem to have figured out a way for "[]" to be used both for arrays and array pointers. Unfortunately, we're stuck with "->" now.
I've been able to accomplish everything I need with TABLES, don't plan on writing a web server on Tachyon ( oh wait there is one) or an FTP server (whoops that's done too) or Telnet (oh gosh how is this all done without formal structures and arrays).
Of course, the TCP/IP stack is not implemented in Tachyon, only the higher level protocols. Your point is still valid though. You don't *have* to have nice data structures to do complex things. It just makes it easier to have them.
Just to make it clear, I'm not trying to discourage others from using Forth. It's just not a good fit for my. Clearly some amazing things can be done in Forth as Peter has demonstrated. I probably spent a thousand hours writing Forth code. I think I could have accomplished the same thing in C in a quarter of the time, but that's just me. Other people like Peter could probably have written the equivalent Forth code in one-tenth the time it took me.
@D.P., one of the things I really like about C is pointers. However, I do agree that the syntax is absolutely awful. Sometimes I get tripped up by using array names as pointers, especially when I use them globally. And the use of "->" versus "." does seem a bit cumbersome. That's where the compiler warnings are useful when I use the wrong syntax sometimes.
Indeed. I've got an industrial project (road sign controller) in front of me and keep thinking -- based on what Peter has demonstrated -- that Tachyon would be a good choice for it. Time to start cracking, I guess!
The link to one of your projects is very impressive Peter.
As I have said before Peter, I am truly amazed at what you have achieved!
Go JonnyMac!
Push up any question you have maybe in the Tachyon thread. I can help you over the "getting started" phase (build, backup, modules, autorun and basics) Then Peter, MJB and others can help you with how to crack the problem (decompose) into Forth Words ( little routines) that you string the program together with in the language terms of the problem domain. Peter is very clever here with this part.
It can be really fun but it's completely different from any other language methodology which can cause some brain pain. Brain pain is good for you.
yes - go -
would be great to have you on board on TACHYON spaceship,
to go where noone has gone before ;-)
and should there be anyting you can not discuss in public there are PM, Email, NDA ...
Markus
It may be done but is it big enough to make anything fit?
Once I get the handle of it I think i could nail it. :-D
Talking about unconventional things that are so much easier to do instead with conventional things I have spoken to people and also over on comp.arch.embedded about the unconventional Propeller chip. After I tell them all the many things I can do with the chip that I know are a problem on other chips they then find dozens of reasons why the Prop can't cut the grade. After all, it doesn't even have interrupts, none at all, and code can only be executed from a really tiny memory, what could anyone do in 496 crippled instructions including registers? It's got to be useless but wait, there are no peripherals to speak of, zero uarts, no a/d, no d/a, no pwm, and the list goes on. Stacked up against the humble Arduino it is obvious which one is more conventional, hence easier to use along with libraries and IDEs etc,
Sound familiar? What convinced you otherwise to be here? Though many of us use all kinds of processor chips we know It wasn't by comparing that got us interested. But we could see what it could do, such a simple almost primitive chip, and we were amazed. Whereas many others were too afraid or comfortable with their "babies" we could see the potential and after all we love exploring new things, so we dipped our big toe in and took the plunge.
To me this mentality is no different when it comes to software, we can't get anywhere if we just compare, but if we look at what it can do, and we at least dip our big toe in to test it out, maybe wade a bit deeper, we may come to have no regrets and instead we become empowered, able to choose the most suitable chip and tool for a job.
It's been a while since I've played with Forth, but I always found it a bit tedious having to keep track of where things are on the stack.
I sympathize Dave, especially when trying to do equations etc that involve the use and reuse of many variables, with lots of intermediate results. I haven't gotten fully up to speed with the factoring, yet. I wrote a set of routines that extend Peter's named variables so that each cog can use them without collision. It is slow, but the coding of complex math becomes trivial, and you can always go back and make it native, so to speak. They are buried in the Tachyon thread, but if you are interested I can repost.
It's been a while since I've played with Forth, but I always found it a bit tedious having to keep track of where things are on the stack.
I sympathize Dave, especially when trying to do equations etc that involve the use and reuse of many variables, with lots of intermediate results. I haven't gotten fully up to speed with the factoring, yet. I wrote a set of routines that extend Peter's named variables so that each cog can use them without collision. It is slow, but the coding of complex math becomes trivial, and you can always go back and make it native, so to speak. They are buried in the Tachyon thread, but if you are interested I can repost.
If you decompose your routines (words) I'm sure you will find no need for all those variables. The saturated vapor pressure equations I need are not trivial, I have them working in spin with F32. When the FP IO is ready in Tachyon 3.x for the new F32 Tachyon ROM I will post them up.
i.e. give them pressure, wet bulb and dry bulb temps and get RH, absolute humidity and dew point. Good times.
But use the correct tool for the job, like I said earlier I use all sorts of web technologies and would not use anything else for this work because it's the only thing that 'computer' (web browser) understands. @Heater crucified himself trying to write a butterfly routine for a FFT in Tachyon, I would have grabbed an FPU and have been done with it and finished the system if it was a real project and I needed all the other stuff in Tachyon (SD Card, Networking, Console, room for my program...) But now I will be able to grab Heater's FFT PASM and wrap it up as a Tachyon ROM if needed. Joy.
It's been a while since I've played with Forth, but I always found it a bit tedious having to keep track of where things are on the stack.
I sympathize Dave, especially when trying to do equations etc that involve the use and reuse of many variables, with lots of intermediate results. I haven't gotten fully up to speed with the factoring, yet. I wrote a set of routines that extend Peter's named variables so that each cog can use them without collision. It is slow, but the coding of complex math becomes trivial, and you can always go back and make it native, so to speak. They are buried in the Tachyon thread, but if you are interested I can repost.
I find that I use the Propeller chip mainly for control purposes and that not even having a multiply instruction that it is ill suited for "equations". Of course it can do them, but not very efficiently. The same too with Tachyon, it is designed for the Prop chip and is used mainly for control purposes and is ill suited for "equations". But then again, it is the language compiler and environment that lives on the Prop available at any time, PC or no PC whereas those "equations" only ever live in the source code on the PC whose compiler requirements dwarfs the meager resources of the Prop chip itself. Some compiled "languages" are better at maths than others, some are better at scientific calculations, some are better at databases etc but surely we would be foolish to be choosing a Prop chip for any of these tasks.
Once again, we are back to comparing instead of understanding where the strength of a particular approach lies. Tachyon is a tool that fits the Prop that fits the job it is designed for.
It may be done but is it big enough to make anything fit?
Once I get the handle of it I think i could nail it. :-D
Talking about unconventional things that are so much easier to do instead with conventional things I have spoken to people and also over on comp.arch.embedded about the unconventional Propeller chip. After I tell them all the many things I can do with the chip that I know are a problem on other chips they then find dozens of reasons why the Prop can't cut the grade. After all, it doesn't even have interrupts, none at all, and code can only be executed from a really tiny memory, what could anyone do in 496 crippled instructions including registers? It's got to be useless but wait, there are no peripherals to speak of, zero uarts, no a/d, no d/a, no pwm, and the list goes on. Stacked up against the humble Arduino it is obvious which one is more conventional, hence easier to use along with libraries and IDEs etc,
Sound familiar? What convinced you otherwise to be here? Though many of us use all kinds of processor chips we know It wasn't by comparing that got us interested. But we could see what it could do, such a simple almost primitive chip, and we were amazed. Whereas many others were too afraid or comfortable with their "babies" we could see the potential and after all we love exploring new things, so we dipped our big toe in and took the plunge.
To me this mentality is no different when it comes to software, we can't get anywhere if we just compare, but if we look at what it can do, and we at least dip our big toe in to test it out, maybe wade a bit deeper, we may come to have no regrets and instead we become empowered, able to choose the most suitable chip and tool for a job.
These quotes about why the prop is no good for anything really give me the creeps!
Oh it doesn't have interrupts - its not a negative, but rather a positive - you just cannot convince most people.
Small code per cog - but there are 8 of them, then there is the spin interpreter, and there is LMM.
No peripherals - what an advantage because you can program whatever you like, and there are also plenty already done for you - 4 simple UARTs in one cog anyone, want more??? -we can do that too!
I have one chip in my arsenal and it does the lot! And whats more, I enjoy working with it too! What a bonus!
BTW While I might be a hobbyist now, in my professional career I was mini-computer hardware and software specialist (also taught hardware maintenance and software programming), and designed and programmed many microprocessor devices (right from 1976 when the micros were basically released), mostly in assembler using interrupts. So it is not as though I don't know other micros, nor how to design or program them - I consider I speak from authority.
You know, I bet there were similar detractors when the Dyson Vacuum Cleaner was released. What, no bag to collect the dirt and dust - No way that can work!
Talking about unconventional things that are so much easier to do instead with conventional things I have spoken to people and also over on comp.arch.embedded about the unconventional Propeller chip. After I tell them all the many things I can do with the chip that I know are a problem on other chips they then find dozens of reasons why the Prop can't cut the grade.
Why either Propeller or other chips?
Some other chips do some stuff easier, better, cheaper, ...
E.g.: Compare Propeller as USB client to ATtiny45/85 or ATmega32u4.
So why either Propeller or other chips?
Make it "and"!
Use whatever fits the job and sometimes it will not be a Propeller...
That's ok.
Simply ok!
Talking about unconventional things that are so much easier to do instead with conventional things I have spoken to people and also over on comp.arch.embedded about the unconventional Propeller chip. After I tell them all the many things I can do with the chip that I know are a problem on other chips they then find dozens of reasons why the Prop can't cut the grade.
Why either Propeller or other chips?
Some other chips do some stuff easier, better, cheaper, ...
E.g.: Compare Propeller as USB client to ATtiny45/85 or ATmega32u4.
So why either Propeller or other chips?
Make it "and"!
Use whatever fits the job and sometimes it will not be a Propeller...
That's ok.
Simply ok!
Obviously that wasn't what I was talking about in my post, I use and have used a huge variety of chips, but if I use the Propeller it's because I know about its strengths and how to use it best. So the post was not about "simply ok" but about the mindset that non-Prop people have that limits them. We are not limited with this mindset when it comes to the Prop, but it seems that we do limit ourselves with the languages and tools that we use with the Prop.
Comments
And then there is the non-adherence to standards and the lack of portability. I understand that Forth is less efficient when it tries to adhere to a standard, so it's understandable that there are so many variants of Forth. Other languages are able to maintain strict adherence to standards while at the same time they generate code is quite efficient. The use of standards allows development on other machine, and makes porting to the target machine easier. As an example, I can develop C code on almost any platform and thoroughly test it before I even try it on a Prop. And in most cases I can then run the code on the Prop without making a single change in the source code.
I can't stand C's pointers, never have, never will. The syntax is absolutely awful.
I don't plan on porting my saturated vapor pressure equations using F32 / Tachyon written for a Propeller 1 to the nearest PDP-11 Dave. We are not talking mainframes here but specialized microprocessors and P1 has already blown the mold. I've been able to accomplish everything I need with TABLES, don't plan on writing a web server on Tachyon ( oh wait there is one) or an FTP server (whoops that's done too) or Telnet (oh gosh how is this all done without formal structures and arrays).
Yes well I'm not sorry for the snark, you mentioned you like compilers checking your work earlier, well when I break out my paints and canvass I don't need a line drawing on the page, with great freedom comes responsibility. Tachyon assumes your are a professional if you are gonna release a professional product base on the the "system". Also if you do proper functional decomposition and test the little WORDS as you go then the compiler's precious bounds checking et al is moot. This is great when I have a new chip without a driver and need few quick words to get at its guts. The last driver I wrote the other day was for this cool chip:
MAX31856 universal type Thermocouple-to-digital converter
Measures full range for B, E, J, K, N, R, S and T thermocouple types
19-bit SPI interface
AND I AM A NOVICE forth programmer but I am a digital god behind a Tachyon console, at least in my mind.
Anyway, some like C some don't. I like Tachyon/P1 as a complete system (not just a language and compiler) that is out of this world extensible.
Have a great day and I do mean this, you are a very talented person as can be seen by your great contributions to P1.
Go JonnyMac!
Push up any question you have maybe in the Tachyon thread. I can help you over the "getting started" phase (build, backup, modules, autorun and basics) Then Peter, MJB and others can help you with how to crack the problem (decompose) into Forth Words ( little routines) that you string the program together with in the language terms of the problem domain. Peter is very clever here with this part.
It can be really fun but it's completely different from any other language methodology which can cause some brain pain. Brain pain is good for you.
Seems we have this Forth vs any other language debate every year or so. All the points raised here can be found in other old Forth/Tachyon threads.
It is said that "A poor craftsman blames his tools"
Here we have a great example of an excellent craftsman, Peter, who builds his own tools first, the way he likes them, then gets the job done.
Others have built C for the Prop, and a bunch of other systems. It's all good.
Agreed, look out for your fingers when using __any type of hammer.
You just started me thinking there should be a programming language called "Hammer" and that I might have to create one.
A quick google shows it's already done, of course:
http://hammer-language.com
Ah well.
I'll just have to get back to ZiCog. We need a Z80 emulator for the P2 right? Still the only way to actually compile C code on the Prop itself
@D.P., one of the things I really like about C is pointers. However, I do agree that the syntax is absolutely awful. Sometimes I get tripped up by using array names as pointers, especially when I use them globally. And the use of "->" versus "." does seem a bit cumbersome. That's where the compiler warnings are useful when I use the wrong syntax sometimes.
would be great to have you on board on TACHYON spaceship,
to go where noone has gone before ;-)
and should there be anyting you can not discuss in public there are PM, Email, NDA ...
Markus
It may be done but is it big enough to make anything fit?
Once I get the handle of it I think i could nail it. :-D
Talking about unconventional things that are so much easier to do instead with conventional things I have spoken to people and also over on comp.arch.embedded about the unconventional Propeller chip. After I tell them all the many things I can do with the chip that I know are a problem on other chips they then find dozens of reasons why the Prop can't cut the grade. After all, it doesn't even have interrupts, none at all, and code can only be executed from a really tiny memory, what could anyone do in 496 crippled instructions including registers? It's got to be useless but wait, there are no peripherals to speak of, zero uarts, no a/d, no d/a, no pwm, and the list goes on. Stacked up against the humble Arduino it is obvious which one is more conventional, hence easier to use along with libraries and IDEs etc,
Sound familiar? What convinced you otherwise to be here? Though many of us use all kinds of processor chips we know It wasn't by comparing that got us interested. But we could see what it could do, such a simple almost primitive chip, and we were amazed. Whereas many others were too afraid or comfortable with their "babies" we could see the potential and after all we love exploring new things, so we dipped our big toe in and took the plunge.
To me this mentality is no different when it comes to software, we can't get anywhere if we just compare, but if we look at what it can do, and we at least dip our big toe in to test it out, maybe wade a bit deeper, we may come to have no regrets and instead we become empowered, able to choose the most suitable chip and tool for a job.
If you decompose your routines (words) I'm sure you will find no need for all those variables. The saturated vapor pressure equations I need are not trivial, I have them working in spin with F32. When the FP IO is ready in Tachyon 3.x for the new F32 Tachyon ROM I will post them up.
i.e. give them pressure, wet bulb and dry bulb temps and get RH, absolute humidity and dew point. Good times.
But use the correct tool for the job, like I said earlier I use all sorts of web technologies and would not use anything else for this work because it's the only thing that 'computer' (web browser) understands. @Heater crucified himself trying to write a butterfly routine for a FFT in Tachyon, I would have grabbed an FPU and have been done with it and finished the system if it was a real project and I needed all the other stuff in Tachyon (SD Card, Networking, Console, room for my program...) But now I will be able to grab Heater's FFT PASM and wrap it up as a Tachyon ROM if needed. Joy.
I find that I use the Propeller chip mainly for control purposes and that not even having a multiply instruction that it is ill suited for "equations". Of course it can do them, but not very efficiently. The same too with Tachyon, it is designed for the Prop chip and is used mainly for control purposes and is ill suited for "equations". But then again, it is the language compiler and environment that lives on the Prop available at any time, PC or no PC whereas those "equations" only ever live in the source code on the PC whose compiler requirements dwarfs the meager resources of the Prop chip itself. Some compiled "languages" are better at maths than others, some are better at scientific calculations, some are better at databases etc but surely we would be foolish to be choosing a Prop chip for any of these tasks.
Once again, we are back to comparing instead of understanding where the strength of a particular approach lies. Tachyon is a tool that fits the Prop that fits the job it is designed for.
These quotes about why the prop is no good for anything really give me the creeps!
Oh it doesn't have interrupts - its not a negative, but rather a positive - you just cannot convince most people.
Small code per cog - but there are 8 of them, then there is the spin interpreter, and there is LMM.
No peripherals - what an advantage because you can program whatever you like, and there are also plenty already done for you - 4 simple UARTs in one cog anyone, want more??? -we can do that too!
I have one chip in my arsenal and it does the lot! And whats more, I enjoy working with it too! What a bonus!
BTW While I might be a hobbyist now, in my professional career I was mini-computer hardware and software specialist (also taught hardware maintenance and software programming), and designed and programmed many microprocessor devices (right from 1976 when the micros were basically released), mostly in assembler using interrupts. So it is not as though I don't know other micros, nor how to design or program them - I consider I speak from authority.
You know, I bet there were similar detractors when the Dyson Vacuum Cleaner was released. What, no bag to collect the dirt and dust - No way that can work!
Some other chips do some stuff easier, better, cheaper, ...
E.g.: Compare Propeller as USB client to ATtiny45/85 or ATmega32u4.
So why either Propeller or other chips?
Make it "and"!
Use whatever fits the job and sometimes it will not be a Propeller...
That's ok.
Simply ok!
Obviously that wasn't what I was talking about in my post, I use and have used a huge variety of chips, but if I use the Propeller it's because I know about its strengths and how to use it best. So the post was not about "simply ok" but about the mindset that non-Prop people have that limits them. We are not limited with this mindset when it comes to the Prop, but it seems that we do limit ourselves with the languages and tools that we use with the Prop.