Well, if that is true, everything continues to work fine. Then clearly they did not need mooching in the first place! We have implemented a feature into the Propeller that is not even needed!
Agree. Which is why I claim that the only schemes that (currently) make sense are a single cog mooching (i.e. "SuperCog"), which is basically only guaranteed to be able to mooch as many cogs as you leave unused since all the others will be fought over - and pairing, which is basically the same as a 2-cog driver.
None of the other proposals seem to be to be "in keeping" with the Propeller architecture. They seem to want to turn the Propeller into a "poor man's XMOS" with all its complexity and consequent lack of commercial success.
It all depends on whether or not people depend on the moocher. If a more zippy main program is needed, or would just be desirable, great! Mooch is there. On the other hand, if somebody really wants that moocher to get it done consistently, don't depend on the moocher.
That's what pairing is for.
Here's the difference:
Video signal and line buffer driver, maybe a bitmap to keep it simple. If that one is mooching, and somebody loads up the Propeller, it's going to show some display glitches at best, lose sync or deliver a crappy signal at worst, depending on how it's written. Mooch is definitely not cool here. Pairing could really shine here. During video scan, the signal COG dominates, consuming a lot of the paired hub cycles. During blank, it could hand those back to the other COG in the pair, where it may update a sprite list or something. Maybe recompute display parameters to respond to a resolution change, or system clock change, etc...
Sprite engine, multi-COG. Sprites fail somewhat gracefully, and there are little failures in those anyway, usually boiling down to how many concurrent sprites are displayed on a single scan line. As the objects move around, exceeding that limit might see one partially displayed, or just not displayed, or it may flicker, depending on how it's all built up. When they don't all display, it's not the end of the world. Choice is back off on some other COGS to improve the mooching potential, or simply add another sprite COG to increase the number of concurrent ones per line, or pair COGS, etc...
Tubular,
Not necessarily. If we are programming in C I can write a driver and compile it into an object file or library archive and give that binary file to you.
You can then link it into the C program you are creating.
Yes understood, but PH was referring to a _code protected_ binary blob - which to me implies the full image, in which case the hub mechanism is hidden from the user, and therefore could be almost any scheme
Is there a way to code protect partial binary libraries? I know you can do this on PLCs, FPGAs etc.
"Heater was right" you will be thinking to yourself.
None of the other proposals seem to be to be "in keeping" with the Propeller architecture.
That is my feeling.
They seem to want to turn the Propeller into a "poor man's XMOS"
The schemes suggested make an XMOS look more like a "Propeller" than the Propeller 2 might become:)
"poor man's XMOS"
Uggh, "A poor mans XMOS" is, well, an XMOS. The smallest cheapest chip is 4.28 dollars the biggest only 23 dollars. Lot's of perfect, high speed, determinism to be had for cheap.
...with all its complexity...
Perhaps, but that is not an issue for all the "professionals" like we have around here right?
...consequent lack of commercial success
Uggh, XMOS has been around for years now. They recently attracted another 14 million investment from Amadeus and others. Those guys would not be putting up money if the did not see a return coming in.
At least not one that is generally applicable to the community of Prop programmers.
Ah... and so we leap from the technical, to the 'someone's feelings' and even tho you (in the same post!) agree that
Any merge of parallel Cores to common shared RAM, is going to have similar issues.
and also At some stage, system allocation decisions need to be made.
yet you do not want to deliver a solution, that allows "the community of Prop programmers" to choose for themselves.
ergo a failure in logical thinking.
yet you do not want to deliver a solution, that allows "the community of Prop programmers" to choose for themselves.
ergo a failure in logical thinking.
More likely that he does not want to see a solution that will forever see the Propeller written off as "difficult to program, and prone to mysterious failures".
More likely that he does not want to see a solution that will forever see the Propeller written off as "difficult to program, and prone to mysterious failures".
Really ? or just more Hyperbole ? "It's the poor craftsman who blames his tools."
...and so we leap from the technical, to the 'someone's feelings'...
This is not a technical debate. Or should I say, again, it is not entirely technical, there is a lot of value judgement going on here. Some value simplicity and determinism. Others value squeezing out the last cycle no matter what. Some want that code "always works, anywhere, in any ones project no matter what it is mixed with", some say "To hell with that I want those last few MIPs no matter what chaos it causes for others."
So yes. it's always been subjective, on your side as well as mine.
"Bla, bla, ... ergo a failure in logical thinking.".
Well, I'm as prone to errors in logical thinking as the next guy. I'll let other's evaluate the logical consistency of these arguments for themselves
Hyperbole? Who me?
"It's the poor craftsman who blames his tools."
Perhaps. Have you ever noticed that there are hundreds of times more "poor craftsmen" in the world than grand masters? It would be a big mistake to purposely exclude such a big market segment my making things so complex that only the top few percent have the time and intellect available to master it.
This is not a technical debate. Or should I say, again, it is not entirely technical, there is a lot of value judgement going on here. Some value simplicity and determinism. Others value squeezing out the last cycle no matter what. Some want that code "always works, anywhere, in any ones project no matter what it is mixed with", some say "To hell with that I want those last few MIPs no matter what chaos it causes for others."
So yes. it's always been subjective
I have the perfect solution to subjective (non technical) choices :
Parallax make TWO variants, Fuse Selected.Solved!
For your "Need Protection" users, they order the PartOne - the Advanced features are fused off. (easily done)
For the "need control" users, they order the PartTwo, with a run time choice of on, or off.
Libraries are qualified for PartOne and that user never needs know about PartTwo. After all, they are not even buying it !!
The PartTwo users do not taint the PartOne users, with their experience, or 'perceptions', either good or bad.
Since this tainting is such a perceived issue to some, Parallax could even have two forums.
PartOne users can upgrade to PartTwo, but very few will ever want to, because they believe all problems can be solved with PartOne. (just-use-more-cogs, they chant)
PartTwo users, are meanwhile free to get on with making their design choices, as they always have done.Technically.
Everyone wins. This Great Idea could even need it's own thread ?
It strikes me that hub slot arrangements are the perfect departure point for each to have their own verilog P2 to experiment with, as has been considered by Parallax
The same people who would really benefit from the hub slot flexibility are the same people who are quite capable of experimenting with FPGAs
It strikes me that hub slot arrangements are the perfect departure point for each to have their own verilog P2 to experiment with, as has been considered by Parallax
The same people who would really benefit from the hub slot flexibility are the same people who are quite capable of experimenting with FPGAs
Works for me - and Parallax could manufacture one wafer run, with a Fuse to select hub slot (and probably other) operational variants. P1+ is a good place to start.
Well, if I was a typical customer, probably neither. I'd probably take a quick glance at the data sheets, and then (when I couldn't figure anything out from them because of their complexity) I'd probably visit the Parallax online discussion forums - where no doubt I'd find many users complaining about how they just can't get their "PartOne" OBEX objects to work reliably on their supposedly higher-performance "PartTwo" chips ... and then I'd go order an XMOS or a Cortex-M4.
Agree. Which is why I claim that the only schemes that (currently) make sense are a single cog mooching (i.e. "SuperCog"), which is basically only guaranteed to be able to mooch as many cogs as you leave unused since all the others will be fought over - and pairing, which is basically the same as a 2-cog driver.
None of the other proposals seem to be to be "in keeping" with the Propeller architecture. They seem to want to turn the Propeller into a "poor man's XMOS" with all its complexity and consequent lack of commercial success.
Ross.
XMOS seems to be doing well, with several design wins:
and this: "XML is like violence. Sure, it seems like a quick and easy solution at first, but then it spirals out of control into utter chaos."
along with other choice quotes here: http://http://quotes.cat-v.org/programming/
Well, if I was a typical customer, probably neither. I'd probably take a quick glance at the data sheets, and then (when I couldn't figure anything out from them because of their complexity)
Really? yet the PartOne device, is exactly what is in the pipeline now ?
You claimed it was simple before, now you have flipped to complex ?
This delivers exactly what you asked - stable objects, all having a defined slot scheme, and all with 'no surprises', on a chip that works as ordered. If that was really what you were looking for, you have found it.
Other users are free to select PartTwo, as better suited to their type of projects.
Really? yet the PartOne device, is exactly what is in the pipeline now ?
You claimed it was simple before, now you have flipped to complex ?
This delivers exactly what you asked - stable objects, all having a defined slot scheme, and all with 'no surprises', on a chip that works as ordered. If that was really what you were looking for, you have found it.
Other users are free to select PartTwo, as better suited to their type of projects.
When trying to identify which specific Propeller to use, you will naturally look at all the family data sheets. Then you will look at which one others are using for your type of application, and then you will look at what problems they are having with them. And then ... well ... you will probably look for another solution.
Comments
Agree. Which is why I claim that the only schemes that (currently) make sense are a single cog mooching (i.e. "SuperCog"), which is basically only guaranteed to be able to mooch as many cogs as you leave unused since all the others will be fought over - and pairing, which is basically the same as a 2-cog driver.
None of the other proposals seem to be to be "in keeping" with the Propeller architecture. They seem to want to turn the Propeller into a "poor man's XMOS" with all its complexity and consequent lack of commercial success.
Ross.
It all depends on whether or not people depend on the moocher. If a more zippy main program is needed, or would just be desirable, great! Mooch is there. On the other hand, if somebody really wants that moocher to get it done consistently, don't depend on the moocher.
That's what pairing is for.
Here's the difference:
Video signal and line buffer driver, maybe a bitmap to keep it simple. If that one is mooching, and somebody loads up the Propeller, it's going to show some display glitches at best, lose sync or deliver a crappy signal at worst, depending on how it's written. Mooch is definitely not cool here. Pairing could really shine here. During video scan, the signal COG dominates, consuming a lot of the paired hub cycles. During blank, it could hand those back to the other COG in the pair, where it may update a sprite list or something. Maybe recompute display parameters to respond to a resolution change, or system clock change, etc...
Sprite engine, multi-COG. Sprites fail somewhat gracefully, and there are little failures in those anyway, usually boiling down to how many concurrent sprites are displayed on a single scan line. As the objects move around, exceeding that limit might see one partially displayed, or just not displayed, or it may flicker, depending on how it's all built up. When they don't all display, it's not the end of the world. Choice is back off on some other COGS to improve the mooching potential, or simply add another sprite COG to increase the number of concurrent ones per line, or pair COGS, etc...
Yes understood, but PH was referring to a _code protected_ binary blob - which to me implies the full image, in which case the hub mechanism is hidden from the user, and therefore could be almost any scheme
Is there a way to code protect partial binary libraries? I know you can do this on PLCs, FPGAs etc.
I wouldn't ever entertain any other possibility
A simple method has been delivered, it is just that you then apply this :
Ah... and so we leap from the technical, to the 'someone's feelings' and even tho you (in the same post!) agree that
Any merge of parallel Cores to common shared RAM, is going to have similar issues.
and also
At some stage, system allocation decisions need to be made.
yet you do not want to deliver a solution, that allows "the community of Prop programmers" to choose for themselves.
ergo a failure in logical thinking.
More likely that he does not want to see a solution that will forever see the Propeller written off as "difficult to program, and prone to mysterious failures".
Ross.
Really ? or just more Hyperbole ? "It's the poor craftsman who blames his tools."
Don't worry - I've developed a very simple tool you can use to calculate the hub slot sharing configuration your application will require!
Ross.
So yes. it's always been subjective, on your side as well as mine.
"Bla, bla, ... ergo a failure in logical thinking.".
Well, I'm as prone to errors in logical thinking as the next guy. I'll let other's evaluate the logical consistency of these arguments for themselves
Hyperbole? Who me? Perhaps. Have you ever noticed that there are hundreds of times more "poor craftsmen" in the world than grand masters? It would be a big mistake to purposely exclude such a big market segment my making things so complex that only the top few percent have the time and intellect available to master it.
I have the perfect solution to subjective (non technical) choices :
Parallax make TWO variants, Fuse Selected. Solved!
For your "Need Protection" users, they order the PartOne - the Advanced features are fused off. (easily done)
For the "need control" users, they order the PartTwo, with a run time choice of on, or off.
Libraries are qualified for PartOne and that user never needs know about PartTwo. After all, they are not even buying it !!
The PartTwo users do not taint the PartOne users, with their experience, or 'perceptions', either good or bad.
Since this tainting is such a perceived issue to some, Parallax could even have two forums.
PartOne users can upgrade to PartTwo, but very few will ever want to, because they believe all problems can be solved with PartOne. (just-use-more-cogs, they chant)
PartTwo users, are meanwhile free to get on with making their design choices, as they always have done.Technically.
Everyone wins. This Great Idea could even need it's own thread ?
The same people who would really benefit from the hub slot flexibility are the same people who are quite capable of experimenting with FPGAs
Exactly what we need! More complexity!
No, less, you would order PartOne. Life is simple, and this does address your fears.
Many semiconductor vendors offer more than one variant from the same wafer, and they do that for both technical and commercial reasons.
They charge more for the part he market considers more valuable.
Would you pay more for PartOne, or PartTwo ?
Works for me
Well, if I was a typical customer, probably neither. I'd probably take a quick glance at the data sheets, and then (when I couldn't figure anything out from them because of their complexity) I'd probably visit the Parallax online discussion forums - where no doubt I'd find many users complaining about how they just can't get their "PartOne" OBEX objects to work reliably on their supposedly higher-performance "PartTwo" chips ... and then I'd go order an XMOS or a Cortex-M4.
Ross.
XMOS seems to be doing well, with several design wins:
http://www.xmos.com/news/press
http://www.motifake.com/violence-violence-demotivational-posters-106227.html
and this: "XML is like violence. Sure, it seems like a quick and easy solution at first, but then it spirals out of control into utter chaos."
along with other choice quotes here:
http://http://quotes.cat-v.org/programming/
Really? yet the PartOne device, is exactly what is in the pipeline now ?
You claimed it was simple before, now you have flipped to complex ?
This delivers exactly what you asked - stable objects, all having a defined slot scheme, and all with 'no surprises', on a chip that works as ordered. If that was really what you were looking for, you have found it.
Other users are free to select PartTwo, as better suited to their type of projects.
When trying to identify which specific Propeller to use, you will naturally look at all the family data sheets. Then you will look at which one others are using for your type of application, and then you will look at what problems they are having with them. And then ... well ... you will probably look for another solution.
Ross.