Couldn't have (and obviously didn't) said it better myself. My sentiment, exactly! :nerd:
So I guess it's settled. The Propeller architecture is clearly superior to what came before it and there is no point in discussing this any further. There is no value to any other solutions. Maybe one reason that this discussion comes up over and over is that the people on the Propeller side are too stubborn to consider that any other solution might have any merit. So I guess you're right. This is off topic and against forum policies since it is a religious argument at least on one side.
So I guess it's settled. The Propeller architecture is clearly superior to what came before it and there is no point in discussing this any further. There is no value to any other solutions. Maybe one reason that this discussion comes up over and over is that the people on the Propeller side are too stubborn to consider that any other solution might have any merit. So I guess you're right. This is off topic and against forum policies since it is a religious argument at least on one side.
No doubt, the propeller is superior for a whole world of reasons. I appreciate everyone's input, I have learned alot, and will save this thread in my notes, for further research.
Insofaras the language to program the propeller in, I will have to stick with a sucessfull model, Tachyon. I need to know how Peter did what he did, and try to modulaize
his methods, for communication and project assimilation concerns. If forth is aggrevating like everybody says, it will be a challenge to compartmentlize the code
to adapt to other projects. Wish me luck!
No doubt, the propeller is superior for a whole world of reasons. I appreciate everyone's input, I have learned alot, and will save this thread in my notes, for further research.
Insofaras the language to program the propeller in, I will have to stick with a sucessfull model, Tachyon. I need to know how Peter did what he did, and try to modulaize
his methods, for communication and project assimilation concerns. If forth is aggrevating like everybody says, it will be a challenge to compartmentlize the code
to adapt to other projects. Wish me luck!
Let me preface this: Tachyon is an amazing Forth implementation that let's you easily and interactively wring out Propeller performance in wonderful ways.I love to use it and am continually amazed at Peter's coding skills and have learned a lot about Forth from him. He has also taken the Propeller to commercial implementation many times over.
With that said,you make it sound like the Propeller was an unprogrammable failure up until the arrival of Tachyon. You really need to do more research and look at some of the amazing Spin and PASM code written by others and the projects and software that has been provided in those languages. Phil Pilgrims S2 code is an amazing package put together to run the S2 robot. Beau Scwabe's PW32 and high speed communication code is great, DFS and 4 port FDS are great tools. The OBEX is full of many objects that show the things you can do with the Propeller. There is PASM code that wrings every last drop of performance out of the Propeller for video and many other applications.
There is a growing body of C code for the Propeller.
There are viable commercial applications using any and all of these languages.
There is PropBasic which offers some great speed and power to Propeller programmers and a migration pathway from other MCUs using BASIC dialects. I feel this one has been underplayed and promoted more.
There have been "successful" projects in all of these languages.
Your sticking with a "successful model" is still hard for me to understand. The underlying success of all of these is the Propeller. You OS needs to support the Propeller and all of the tools available to it. You can't force programmers to use a particular tools because you say it is the best and most successful. These dictates and opinions are the fuel of Propeller Language wars every day. If you center on Forth (or any other single tool except perhaps SPIN/PASM), your OS announcement will be met with the resounding roar of crickets.......
Programmers like choice, some actually have figured out that there is great benefit to multiple tools and will use them as they see them fit a problem they are looking to solve.
If you are a Forth programmer (which I have a strong doubt you are), then take Tachyon and run with it and create a Linux/Forth OS distribution that solves the problem you are looking to solve for yourself. As suggested before, if you want to learn more about Forth, read "Starting Forth" and "Thinking Forth" by Leo Brodie - both available on the 'net.
If you are looking to create a Linux/Propeller/Forth release that will be met as an amazing technical achievement, I think you are seeking fame and glory the wrong way.
If you are looking for some commercial success, then you are up against a lot of really good FREE tools that are working fine and have an embedded user base. You won't sway the opinions or dislodge much of this embedded base.
The Propeller is the best solution not because it have/not have: interrupts, multicore, Spin, C, hardware peripherals, good/bad documentation, etc, etc
The Propeller is the best because it is fun!
I have to do my PhD. I am doing an archival sound restoration. I want to do it in FPGA environment. I have a bunch of LEs to cnnect and I need something to rule them all. The physical Propeller chip has to be somewhat soldered and connected to an FPGA board. This could cause all kind of errors. I tried this. I connected a quickstart to DE2-115. Yes, it can blink DE's leds. Then all kind of problems started to rise. So I started to learn NIOS, bought (via my university) a DE1-SoC with ARM, using all Polish equivalents of English f-word when learning all these - another 4-letter word - things.
Then Parallax published the Propeller code and I am again in an environment where I have fun developing. Thank you.
The Propeller is the best solution not because it have/not have: interrupts, multicore, Spin, C, hardware peripherals, good/bad documentation, etc, etc
So I guess it's settled. The Propeller architecture is clearly superior to what came before it and there is no point in discussing this any further. There is no value to any other solutions. Maybe one reason that this discussion comes up over and over is that the people on the Propeller side are too stubborn to consider that any other solution might have any merit. So I guess you're right. This is off topic and against forum policies since it is a religious argument at least on one side.
That is generalizing it a bit. As Phil said this discussion keeps coming up over and over. One thing that hasn't changed is the previous technology (using interrupts) and the fact that the Propeller architecture overcomes those limitations. It doesn't mean there's nothing to discuss. Feel free to discuss things or even make changes to the design. :thumb:
That is generalizing it a bit. As Phil said this discussion keeps coming up over and over. One thing that hasn't changed is the previous technology (using interrupts) and the fact that the Propeller architecture overcomes those limitations. It doesn't mean there's nothing to discuss. Feel free to discuss things or even make changes to the design. :thumb:
"Previous technology" suggests that it is obsolete and no longer has value. I don't believe that is necessarily true. However, I've never tried to argue that the Propeller approach does't have merit. It certainly does.
Interesting...in my comment, "Previous technology" was in no way meant to imply something that has no value. It's interesting how things get perceived. I was going to say existing, except the Propeller has been out for some time. I'm going to stick with my original comment about interrupts at the link I originally posted. That doesn't make anyone else's comments or opinions invalid. I am stating my thoughts.
Interesting...in my comment, "Previous technology" was in no way meant to imply something that has no value. It's interesting how things get perceived. I was going to say existing, except the Propeller has been out for some time. I'm going to stick with my original comment about interrupts at the link I originally posted. That doesn't make anyone else's comments or opinions invalid. I am stating my thoughts.
"I really didn't say everything I said."
--Yogi Berra
I think your description is excellent for placing the Propeller within the context of everything else, particularly for those that are coming into it with lots of outside experience, which sometimes presents challenges, as their sensibilities are somewhat offended. I think what you wrote is valuable.
Interesting...in my comment, "Previous technology" was in no way meant to imply something that has no value. It's interesting how things get perceived. I was going to say existing, except the Propeller has been out for some time. I'm going to stick with my original comment about interrupts at the link I originally posted. That doesn't make anyone else's comments or opinions invalid. I am stating my thoughts.
One obvious limitation in the Propeller approach is that you have a hard limit at 8 COGs at least at the present. Anyway, I think this discussion or argument or whatever it is has outlasted its usefulness if it every had any.
P1 is the size it is, and that size is small. Scope of desirable tasks has grown in the time P1 has been out there, and we've all maximized what P1 can do for us. Some of the, "if it only had..." type discussions get driven by the desire to improve on the scope of practical / possible tasks. Other parts of that discussion are genuine differences in overall philosophy and how that could ripple down into implementation.
P2 will improve on scope of possible / practical tasks, and for a time, make a dent on desirable tasks, though that will always grow in scope as things advance overall.
Seems to me, if we take the understanding we have about how Props work that we have today, and make sure P2 embodies those things, we will get a great data point as to the scale attributes inherent in this Propeller way of doing things. (which is the maximize it argument I posed earlier)
I, for one, am not opposed to adding things, maybe even some very well defined interrupts. But, I really am reluctant to do so before one more iteration of the design ideas is out there. We may find it's excellent! And if so, we would have added complexity, or potentially diluted value with no real return. Doing that makes no sense.
To which, that's often seen as "blind ideology", or "close mindedness" of various kinds. Which is entirely fair, given what we have today is seen as "perfect" or an example of the idea well realized. I don't think P1 is anywhere close to what "The Propeller Way" could be, now that we've done the work to better understand it. The P2 "hot" version, was a killer design! Perhaps "the way" gone too far, or not well focused. So far, the current P2 design may be much closer to optimal. Hope so.
In any case, the number of COGS will have changed, communication paths, number of I/O pins, shared HUB memory implementation, determinism, and a few other variables are all getting a nice tweak, which should tell us a ton about what having no interrupts really can mean, not just what it means today.
So I guess it's settled. The Propeller architecture is clearly superior to what came before it and there is no point in discussing this any further. There is no value to any other solutions.
I cannot speak for others but that is totally not my argument at all.
I love interrupts. I have used interrupts since forever. Interrupts are a solution to the problem at hand: How to handle multiple asynchronous events without the overheads of having your program poll every possible input all the time
Multiple cores is another solution to that same problem.
An 8 core Propeller is as effective a solution to the problem as a single CPU with an 8 input interrupt controller. Except better, of course, because now all my "interrupts" can be processed at the same time. What is not to like about that?
No, what I object to is the idea of mixing up both these solutions into the same architecture. Interrupts are complicated enough, especially for the user. Dealing with multiple cores is also a chip implementation and a programmer burden.
Great, lets put the complexity of both into our design!
And for what reason? Only because there seem to be people who don't understand how to solve their problems without interrupts.
It's as if Ford would have supplied every Model-T with a horse at the front. Why? Because our customers understand how to drive a horse. Or so a modern day "focus group" or "Market Research" outfit would tell Henry at the time.
I, for one, am not opposed to adding things, maybe even some very well defined interrupts
But, where to add these interrupts?
To the cog? So we will have 8 irq inputs?
To the hub? Nothing to interrupt there
And we have nothing to add. We have interrupts in the Propeller.
Let we use one cog as the interrupt controller. It can have some interrupt handlers in it. It waits on peq. When one of Pxx is set, the cog jumps to an interrupt handler defined for this pin and do its work.
These are soft interrupts as we have soft peripherals.
One obvious limitation in the Propeller approach is that you have a hard limit at 8 COGs at least at the present. Anyway, I think this discussion or argument or whatever it is has outlasted its usefulness if it every had any.
Of course everything has a hard limit.
You remind me now of years gone by when our machine control system was based on 8 bit Intel 8085s. For sure we had a hard limit of 8 possible interrupts with the single interrupt controller that was designed into the processor boards.
Our control system was a bit fast, 10,000 pieces of the product per minute, it was complex. 8 interrupts was not enough and even if we had more the CPU would be far too slow to keep up with it all. No, upgrading to the new at the time Intel 286 would not have helped.
Our solution was a four processor 8085 system with shared memory. Helped by a bunch timers for handling the seriously fast PWM input signals.
Does this sound familiar?
We would have killed to get a Propeller on that kind of project!
The real question about Interrupts is about resource utilization. Is the dedication of an entire core a reasonable approach to servicing a medium-frequency, low-latency event?.
We use an entire core for high frequency, time critical events. We put several medium frequency low-latency events on a single cog.
For example, one cog talks to the 10DOF IMU via I2C and collects data from all four devices and write is to memory (only several words, over and over), this keeps the IC2 stream full. Another cog takes the data and displays it on the terminal screen; at 230400 baud it only displays one in several values, but its so fast that your eye couldn't handle more anyway. Another cog logs the data to SD in realtime, this keep the SD stream full. Its all about using the tool in an appropriate way.
The discussion about Interrupt driven implementations being more complex is nonsense - any approach to servicing an event with low-latency is fraught with complexity. Whether that's dealing with reentrancy problems associated with interrupts or managing path length between polling in a cooperative system - the complexity is equivalent. However, it's far simpler to create a framework in which Interrupts are predictable and reliable than it is to create a framework in which code path lengths are predictable and reliable. And, if you don't want an interrupt driven system just don't use that capability. But if you need it and its not there, you're SOL.
We don't NEED to service interrupts, as demonstrated in the references code. Its simpler, just a loop. The events are handled in sufficient time without interruption. This is how we can detect and handle events so fast. But if you don't like doing it that way, by all means use something else. Personally I prefer the easier method,
Actually, I was thinking of eight latches along with a way to set them from one COG and test-and-clear them from another. Almost sounds like what the locks already do. Also, I'd rather that these latches were not in the hub so a COG could "wake up" without waiting for a hub cycle.
..is the dedication of an entire core a reasonable approach to servicing a medium-frequency, low-latency event?
Yep.
If I can program a 32 bit CPU to perform the function of a NOT gate. And if that 32 bit CPU costs me almost nothing because it's in there already doing nothing. That is a big saving over having to go to Digikey and find a 74 whatever it is inverter chip and design my PCB around it. Which has just made my board bigger, complicated my layout, increased the size of my BOM (Bill Of Materials), increased the cost of sourcing parts, made manufacturing more complex, decrease my yield, increased the return rate of failures from customers, and eventually driven me into non-profitability and bankruptcy.
That might be an extreme example but that is the economics of the thing.
Essentially some type of interrupt signaling can be done in a virtual machine.
I did this about 6 years ago in an LMM machine (described on this forum somewhere).
Hardware interrupts are not really necessary .... For people who insist on having it, all that is necessary is some kind of a waitpeq or waitpne instruction or check for an event in the virtual machine.
Some wait* instruction with optional timeout would be very helpful in this and many other cases. Right now there are only a few ways for a wait to end.
Essentially some type of interrupt signaling can be done in a virtual machine.
I did this about 6 years ago in an LMM machine (described on this forum somewhere).
Hardware interrupts are not really necessary .... For people who insist on having it, all that is necessary is some kind of a waitpeq or waitpne instruction or check for an event in the virtual machine.
Some wait* instruction with optional timeout would be very helpful in this and many other cases. Right now there are only a few ways for a wait to end.
This works as long as your program has an event loop but it still doesn't address the question of how to get the COG running the event loop to go into low power mode when no events are pending.
One obvious limitation in the Propeller approach is that you have a hard limit at 8 COGs at least at the present.
I thought it would be a few more years until I heard someone say 8 cores wasn't enough. But it's a sign of the times. People don't think small anymore. I have seen some highly complex programs written on the C=64 that, when it was popular were unheard of. But you'd find these clever programmers who knew how to work with limited resources and really made things shine. And so really good games that used to come on a couple of floppy diskettes now required sometimes multiple DVD-ROMS. Granted the graphics are better and all, but my point is how inefficient a lot of things have become and this leads to two things...people want more memory and/or they think the platform is lacking the memory. Often it is inefficient coding that leads to running out of resources. I have seen it time and time again on the BASIC Stamp.
Someone will ask how to do a certain thing and the replies are, "You can't! You need a Propeller!" When quite often it can be done on the BASIC Stamp. You just have to be efficient and understand how to use the resources you have. You mentioned the "limit" of 8 cores, but the Propeller has, unfortunately, gotten some programmers into the mode of wasting resources. Someone recently came to me with a project that used up all cogs and they needed more. I made one change and got them what they needed and freed another extra cog up. It turns out that they had to open 4 serial ports and were running 4 instances of FullDuplexSerial. I replaced it with FullDuplexSerial4Port and suddenly everything fit. I could have freed two other cogs by writing my own encoder and another routine since they were needlessly using a cog. It shows how easily resources are wasted.
Sure, Chris, but I as thinking of the Z80 as a cog. Imagine eight Z80s and a quarter meg of hub space!
Eight Z80s...hmm, interesting idea. When I was using the Z80 I never found an application that used more than 2 or 3 vectored interrupts. That was a big project with a UART, CTC and PIA chips.
Save for one aspect: And that is scale. P1 is the size it is, and that size is small. Scope of desirable tasks has grown in the time P1 has been out there, and we've all maximized what P1 can do for us.
I'm sure that some people are realizing bigger and bigger projects on the Propeller, but see the first part of this message for my thoughts on wasting resources which I do see happening. About 6 months ago I helped a customer who had tons of text eating up all his code space. Putting that text into the upper 32K of EEPROM solved that issue without using any additional I/O for something like a flash card interface.
I thought it would be a few more years until I heard someone say 8 cores wasn't enough. But it's a sign of the times. People don't think small anymore. I have seen some highly complex programs written on the C=64 that, when it was popular were unheard of. But you'd find these clever programmers who knew how to work with limited resources and really made things shine. And so really good games that used to come on a couple of floppy diskettes now required sometimes multiple DVD-ROMS. Granted the graphics are better and all, but my point is how inefficient a lot of things have become and this leads to two things...people want more memory and/or they think the platform is lacking the memory. Often it is inefficient coding that leads to running out of resources. I have seen it time and time again on the BASIC Stamp.
Someone will ask how to do a certain thing and the replies are, "You can't! You need a Propeller!" When quite often it can be done on the BASIC Stamp. You just have to be efficient and understand how to use the resources you have. You mentioned the "limit" of 8 cores, but the Propeller has, unfortunately, gotten some programmers into the mode of wasting resources. Someone recently came to me with a project that used up all cogs and they needed more. I made one change and got them what they needed and freed another extra cog up. It turns out that they had to open 4 serial ports and were running 4 instances of FullDuplexSerial. I replaced it with FullDuplexSerial4Port and suddenly everything fit. I could have freed two other cogs by writing my own encoder and another routine since they were needlessly using a cog. It shows how easily resources are wasted.
Eight Z80s...hmm, interesting idea. When I was using the Z80 I never found an application that used more than 2 or 3 vectored interrupts. That was a big project with a UART, CTC and PIA chips.
I'm sure that some people are realizing bigger and bigger projects on the Propeller, but see the first part of this message for my thoughts on wasting resources which I do see happening. About 6 months ago I helped a customer who had tons of text eating up all his code space. Putting that text into the upper 32K of EEPROM solved that issue without using any additional I/O for something like a flash card interface.
Not all of us are as good at programming efficiently as you are. Also, many people just piece together objects from OBEX and don't have the ability to refactor them to put multiple functions in a single COG. In any case, you're certainly right that for the vast majority of projects, eight COGs is plenty.
1> With that said,you make it sound like the Propeller was an unprogrammable failure up until the arrival of Tachyon. You really need to do more research and look at some of the amazing Spin and PASM code written by others and the projects and software that has been provided in those languages. Phil Pilgrims S2 code is an amazing package put together to run the S2 robot. Beau Scwabe's PW32 and high speed communication code is great, DFS and 4 port FDS are great tools. The OBEX is full of many objects that show the things you can do with the Propeller. There is PASM code that wrings every last drop of performance out of the Propeller for video and many other applications. 2> Your sticking with a "successful model" is still hard for me to understand. The underlying success of all of these is the Propeller. You OS needs to support the Propeller and all of the tools available to it. You can't force programmers to use a particular tools because you say it is the best and most successful. These dictates and opinions are the fuel of Propeller Language wars every day. If you center on Forth (or any other single tool except perhaps SPIN/PASM), your OS announcement will be met with the resounding roar of crickets....... 3> If you are looking to create a Linux/Propeller/Forth release that will be met as an amazing technical achievement, I think you are seeking fame and glory the wrong way.
1> If I have been interpreted/implied as saying that, I did not mean that.:frown: My research begins with asking people, such as yourself, to please give me their advice.
2> given this quote from Peter J, from Forth or no Forth, in response to Heater; ** For once and for all put your money where your big bad mouth is and show us all how we can run with the fantabulous magic dare-not-challenge C, what I'm running now in Tachyon Forth with my SD filesystem and network servers etc on a plain old Prop with room left over for a sizable app too.????????? (So benchmark demos don't cut it) ** Very interesting claim. Peter J does not Think his version is faster/more efficent, he knows. How is this possible? Peter J. has already done the math. Even if Heater did manage to make a C program that
met the challenge, Peter would convert it to Tachyon format, and make it ever faster, making him more profitable. He wins either way. In this case, not adapting to Tachyon is some way, is foolish, and
a waste of time. Irreguardless of how I may feel, logic indicates the use of a successfull model to learn upon. Not to say that others are not.
3> Reading through the forum threads, I find alot of propeller software that did not meet the expectations of the user. In my efforts to make propeller projects later on, I find that
a Operating System on the PC would serve my needs. Complete Projects, code, emulators, PASM, and basically any software for the Propeller I can get my hands on, I will
run on that system. This is to ensure that I am completing the propeller project, not fighting the development software that I am using. I make enough stupid mistakes, I do not need
an operating system helping me with that. As for Fame and Glory, if you use the OS, and are happy using it, and/or make money, that is all the thanks I need.(Freeware) "I stand on the shoulders
of giants", as Newton said. We all depend on each other for help, no matter the success/failure.
Not all of us are as good at programming efficiently as you are. Also, many people just piece together objects from OBEX and don't have the ability to refactor them to put multiple functions in a single COG. In any case, you're certainly right that for the vast majority of projects, eight COGs is plenty.
If we want to set new standards for code efficiency we should look at some of the things that Chip Gracey and Jeff Martin have done. Most which haven't been released to the public because they're not immediately cleat to everyone. Some very efficient coding when they have time to minimize it.
1> If I have been interpreted/implied as saying that, I did not mean that.:frown: My research begins with asking people, such as yourself, to please give me their advice.
2> given this quote from Peter J, from Forth or no Forth, in response to Heater; ** For once and for all put your money where your big bad mouth is and show us all how we can run with the fantabulous magic dare-not-challenge C, what I'm running now in Tachyon Forth with my SD filesystem and network servers etc on a plain old Prop with room left over for a sizable app too.????????? (So benchmark demos don't cut it) ** Very interesting claim. Peter J does not Think his version is faster/more efficent, he knows. How is this possible? Peter J. has already done the math. Even if Heater did manage to make a C program that
met the challenge, Peter would convert it to Tachyon format, and make it ever faster, making him more profitable. He wins either way. In this case, not adapting to Tachyon is some way, is foolish, and
a waste of time. Irreguardless of how I may feel, logic indicates the use of a successfull model to learn upon. Not to say that others are not.
3> Reading through the forum threads, I find alot of propeller software that did not meet the expectations of the user. In my efforts to make propeller projects later on, I find that
a Operating System on the PC would serve my needs. Complete Projects, code, emulators, PASM, and basically any software for the Propeller I can get my hands on, I will
run on that system. This is to ensure that I am completing the propeller project, not fighting the development software that I am using. I make enough stupid mistakes, I do not need
an operating system helping me with that. As for Fame and Glory, if you use the OS, and are happy using it, and/or make money, that is all the thanks I need.(Freeware) "I stand on the shoulders
of giants", as Newton said. We all depend on each other for help, no matter the success/failure.
I think you really really really need to dive in and try out a few propeller languages yourself. Given the scope of what you say you want to do you really should try at a minimum SPIN, PASM, PropGCC or Catalina, and or more of the Forths.
Just because Peter has been successful with Tachyon does not mean others will be, they might, but they might not.
Research can only take you so far, especially when a lot of it is based on individual preferences, you really need to dig in and let the bits fly if you want to gain some true understanding.
Comments
No doubt, the propeller is superior for a whole world of reasons. I appreciate everyone's input, I have learned alot, and will save this thread in my notes, for further research.
Insofaras the language to program the propeller in, I will have to stick with a sucessfull model, Tachyon. I need to know how Peter did what he did, and try to modulaize
his methods, for communication and project assimilation concerns. If forth is aggrevating like everybody says, it will be a challenge to compartmentlize the code
to adapt to other projects. Wish me luck!
Let me preface this: Tachyon is an amazing Forth implementation that let's you easily and interactively wring out Propeller performance in wonderful ways.I love to use it and am continually amazed at Peter's coding skills and have learned a lot about Forth from him. He has also taken the Propeller to commercial implementation many times over.
With that said,you make it sound like the Propeller was an unprogrammable failure up until the arrival of Tachyon. You really need to do more research and look at some of the amazing Spin and PASM code written by others and the projects and software that has been provided in those languages. Phil Pilgrims S2 code is an amazing package put together to run the S2 robot. Beau Scwabe's PW32 and high speed communication code is great, DFS and 4 port FDS are great tools. The OBEX is full of many objects that show the things you can do with the Propeller. There is PASM code that wrings every last drop of performance out of the Propeller for video and many other applications.
There is a growing body of C code for the Propeller.
There are viable commercial applications using any and all of these languages.
There is PropBasic which offers some great speed and power to Propeller programmers and a migration pathway from other MCUs using BASIC dialects. I feel this one has been underplayed and promoted more.
There have been "successful" projects in all of these languages.
Your sticking with a "successful model" is still hard for me to understand. The underlying success of all of these is the Propeller. You OS needs to support the Propeller and all of the tools available to it. You can't force programmers to use a particular tools because you say it is the best and most successful. These dictates and opinions are the fuel of Propeller Language wars every day. If you center on Forth (or any other single tool except perhaps SPIN/PASM), your OS announcement will be met with the resounding roar of crickets.......
Programmers like choice, some actually have figured out that there is great benefit to multiple tools and will use them as they see them fit a problem they are looking to solve.
If you are a Forth programmer (which I have a strong doubt you are), then take Tachyon and run with it and create a Linux/Forth OS distribution that solves the problem you are looking to solve for yourself. As suggested before, if you want to learn more about Forth, read "Starting Forth" and "Thinking Forth" by Leo Brodie - both available on the 'net.
If you are looking to create a Linux/Propeller/Forth release that will be met as an amazing technical achievement, I think you are seeking fame and glory the wrong way.
If you are looking for some commercial success, then you are up against a lot of really good FREE tools that are working fine and have an embedded user base. You won't sway the opinions or dislodge much of this embedded base.
The Propeller is the best because it is fun!
I have to do my PhD. I am doing an archival sound restoration. I want to do it in FPGA environment. I have a bunch of LEs to cnnect and I need something to rule them all. The physical Propeller chip has to be somewhat soldered and connected to an FPGA board. This could cause all kind of errors. I tried this. I connected a quickstart to DE2-115. Yes, it can blink DE's leds. Then all kind of problems started to rise. So I started to learn NIOS, bought (via my university) a DE1-SoC with ARM, using all Polish equivalents of English f-word when learning all these - another 4-letter word - things.
Then Parallax published the Propeller code and I am again in an environment where I have fun developing. Thank you.
That is generalizing it a bit. As Phil said this discussion keeps coming up over and over. One thing that hasn't changed is the previous technology (using interrupts) and the fact that the Propeller architecture overcomes those limitations. It doesn't mean there's nothing to discuss. Feel free to discuss things or even make changes to the design. :thumb:
"I really didn't say everything I said."
--Yogi Berra
I think your description is excellent for placing the Propeller within the context of everything else, particularly for those that are coming into it with lots of outside experience, which sometimes presents challenges, as their sensibilities are somewhat offended. I think what you wrote is valuable.
P1 is the size it is, and that size is small. Scope of desirable tasks has grown in the time P1 has been out there, and we've all maximized what P1 can do for us. Some of the, "if it only had..." type discussions get driven by the desire to improve on the scope of practical / possible tasks. Other parts of that discussion are genuine differences in overall philosophy and how that could ripple down into implementation.
P2 will improve on scope of possible / practical tasks, and for a time, make a dent on desirable tasks, though that will always grow in scope as things advance overall.
Seems to me, if we take the understanding we have about how Props work that we have today, and make sure P2 embodies those things, we will get a great data point as to the scale attributes inherent in this Propeller way of doing things. (which is the maximize it argument I posed earlier)
I, for one, am not opposed to adding things, maybe even some very well defined interrupts. But, I really am reluctant to do so before one more iteration of the design ideas is out there. We may find it's excellent! And if so, we would have added complexity, or potentially diluted value with no real return. Doing that makes no sense.
To which, that's often seen as "blind ideology", or "close mindedness" of various kinds. Which is entirely fair, given what we have today is seen as "perfect" or an example of the idea well realized. I don't think P1 is anywhere close to what "The Propeller Way" could be, now that we've done the work to better understand it. The P2 "hot" version, was a killer design! Perhaps "the way" gone too far, or not well focused. So far, the current P2 design may be much closer to optimal. Hope so.
In any case, the number of COGS will have changed, communication paths, number of I/O pins, shared HUB memory implementation, determinism, and a few other variables are all getting a nice tweak, which should tell us a ton about what having no interrupts really can mean, not just what it means today.
I love interrupts. I have used interrupts since forever. Interrupts are a solution to the problem at hand: How to handle multiple asynchronous events without the overheads of having your program poll every possible input all the time
Multiple cores is another solution to that same problem.
An 8 core Propeller is as effective a solution to the problem as a single CPU with an 8 input interrupt controller. Except better, of course, because now all my "interrupts" can be processed at the same time. What is not to like about that?
No, what I object to is the idea of mixing up both these solutions into the same architecture. Interrupts are complicated enough, especially for the user. Dealing with multiple cores is also a chip implementation and a programmer burden.
Great, lets put the complexity of both into our design!
And for what reason? Only because there seem to be people who don't understand how to solve their problems without interrupts.
It's as if Ford would have supplied every Model-T with a horse at the front. Why? Because our customers understand how to drive a horse. Or so a modern day "focus group" or "Market Research" outfit would tell Henry at the time.
But, where to add these interrupts?
To the cog? So we will have 8 irq inputs?
To the hub? Nothing to interrupt there
And we have nothing to add. We have interrupts in the Propeller.
Let we use one cog as the interrupt controller. It can have some interrupt handlers in it. It waits on peq. When one of Pxx is set, the cog jumps to an interrupt handler defined for this pin and do its work.
These are soft interrupts as we have soft peripherals.
before we say Yay or Neighhhhhhhh!
A 32 bit port for message passing between COGs??
Of course everything has a hard limit.
You remind me now of years gone by when our machine control system was based on 8 bit Intel 8085s. For sure we had a hard limit of 8 possible interrupts with the single interrupt controller that was designed into the processor boards.
Our control system was a bit fast, 10,000 pieces of the product per minute, it was complex. 8 interrupts was not enough and even if we had more the CPU would be far too slow to keep up with it all. No, upgrading to the new at the time Intel 286 would not have helped.
Our solution was a four processor 8085 system with shared memory. Helped by a bunch timers for handling the seriously fast PWM input signals.
Does this sound familiar?
We would have killed to get a Propeller on that kind of project!
We use an entire core for high frequency, time critical events. We put several medium frequency low-latency events on a single cog.
For example, one cog talks to the 10DOF IMU via I2C and collects data from all four devices and write is to memory (only several words, over and over), this keeps the IC2 stream full. Another cog takes the data and displays it on the terminal screen; at 230400 baud it only displays one in several values, but its so fast that your eye couldn't handle more anyway. Another cog logs the data to SD in realtime, this keep the SD stream full. Its all about using the tool in an appropriate way.
https://code.google.com/p/propforth/wiki/GY80
We don't NEED to service interrupts, as demonstrated in the references code. Its simpler, just a loop. The events are handled in sufficient time without interruption. This is how we can detect and handle events so fast. But if you don't like doing it that way, by all means use something else. Personally I prefer the easier method,
Neighhhhhhhh!
I'm going to try really hard to forget I saw that picture.
You are seriously upsetting my world model.
Proving everyone has a purpose!
Yep.
If I can program a 32 bit CPU to perform the function of a NOT gate. And if that 32 bit CPU costs me almost nothing because it's in there already doing nothing. That is a big saving over having to go to Digikey and find a 74 whatever it is inverter chip and design my PCB around it. Which has just made my board bigger, complicated my layout, increased the size of my BOM (Bill Of Materials), increased the cost of sourcing parts, made manufacturing more complex, decrease my yield, increased the return rate of failures from customers, and eventually driven me into non-profitability and bankruptcy.
That might be an extreme example but that is the economics of the thing.
Essentially some type of interrupt signaling can be done in a virtual machine.
I did this about 6 years ago in an LMM machine (described on this forum somewhere).
Hardware interrupts are not really necessary .... For people who insist on having it, all that is necessary is some kind of a waitpeq or waitpne instruction or check for an event in the virtual machine.
Some wait* instruction with optional timeout would be very helpful in this and many other cases. Right now there are only a few ways for a wait to end.
I thought it would be a few more years until I heard someone say 8 cores wasn't enough. But it's a sign of the times. People don't think small anymore. I have seen some highly complex programs written on the C=64 that, when it was popular were unheard of. But you'd find these clever programmers who knew how to work with limited resources and really made things shine. And so really good games that used to come on a couple of floppy diskettes now required sometimes multiple DVD-ROMS. Granted the graphics are better and all, but my point is how inefficient a lot of things have become and this leads to two things...people want more memory and/or they think the platform is lacking the memory. Often it is inefficient coding that leads to running out of resources. I have seen it time and time again on the BASIC Stamp.
Someone will ask how to do a certain thing and the replies are, "You can't! You need a Propeller!" When quite often it can be done on the BASIC Stamp. You just have to be efficient and understand how to use the resources you have. You mentioned the "limit" of 8 cores, but the Propeller has, unfortunately, gotten some programmers into the mode of wasting resources. Someone recently came to me with a project that used up all cogs and they needed more. I made one change and got them what they needed and freed another extra cog up. It turns out that they had to open 4 serial ports and were running 4 instances of FullDuplexSerial. I replaced it with FullDuplexSerial4Port and suddenly everything fit. I could have freed two other cogs by writing my own encoder and another routine since they were needlessly using a cog. It shows how easily resources are wasted.
Eight Z80s...hmm, interesting idea. When I was using the Z80 I never found an application that used more than 2 or 3 vectored interrupts. That was a big project with a UART, CTC and PIA chips.
I'm sure that some people are realizing bigger and bigger projects on the Propeller, but see the first part of this message for my thoughts on wasting resources which I do see happening. About 6 months ago I helped a customer who had tons of text eating up all his code space. Putting that text into the upper 32K of EEPROM solved that issue without using any additional I/O for something like a flash card interface.
2> given this quote from Peter J, from Forth or no Forth, in response to Heater;
** For once and for all put your money where your big bad mouth is and show us all how we can run with the fantabulous magic dare-not-challenge C, what I'm running now in Tachyon Forth with my SD filesystem and network servers etc on a plain old Prop with room left over for a sizable app too.????????? (So benchmark demos don't cut it) **
Very interesting claim. Peter J does not Think his version is faster/more efficent, he knows. How is this possible? Peter J. has already done the math. Even if Heater did manage to make a C program that
met the challenge, Peter would convert it to Tachyon format, and make it ever faster, making him more profitable. He wins either way. In this case, not adapting to Tachyon is some way, is foolish, and
a waste of time. Irreguardless of how I may feel, logic indicates the use of a successfull model to learn upon. Not to say that others are not.
3> Reading through the forum threads, I find alot of propeller software that did not meet the expectations of the user. In my efforts to make propeller projects later on, I find that
a Operating System on the PC would serve my needs. Complete Projects, code, emulators, PASM, and basically any software for the Propeller I can get my hands on, I will
run on that system. This is to ensure that I am completing the propeller project, not fighting the development software that I am using. I make enough stupid mistakes, I do not need
an operating system helping me with that. As for Fame and Glory, if you use the OS, and are happy using it, and/or make money, that is all the thanks I need.(Freeware) "I stand on the shoulders
of giants", as Newton said. We all depend on each other for help, no matter the success/failure.
If we want to set new standards for code efficiency we should look at some of the things that Chip Gracey and Jeff Martin have done. Most which haven't been released to the public because they're not immediately cleat to everyone. Some very efficient coding when they have time to minimize it.
I think you really really really need to dive in and try out a few propeller languages yourself. Given the scope of what you say you want to do you really should try at a minimum SPIN, PASM, PropGCC or Catalina, and or more of the Forths.
Just because Peter has been successful with Tachyon does not mean others will be, they might, but they might not.
Research can only take you so far, especially when a lot of it is based on individual preferences, you really need to dig in and let the bits fly if you want to gain some true understanding.
C.W.