TBH, if you're going to start making a chip with a mix of P1 and P2 COGs you may as well just drop an M4 core, an SDRAM die and a P8X32 die into the same package and be done with it. Simplicity sells.
I agree it would be a way forward, but I'm afraid it could overwhelm people who'd be faced with two different things to learn. It could really complicate the tools, like Heater pointed out.
It's much like treating the P2 cog like a FPU, or GPU and the P1 COGs like a uC ?
Meanwhile, see how much common-stuff it is possible to pull off a P2 COG to shrink it to a object-compatible subset.
I like your shrink-via-shared-common 'big ops' logic idea.
One method to improve tools and learning would be to clone only P1 opcodes, in P2 binary subset, that would at least allow a P1S (S for Subset Compatible) object to run in a P2 host.
That shifts 'different' to 'subset' which is easier to learn. Simple Illegal opcode coverage could catch the other direction.
I would say, faster but less deterministic and smaller size COG RAM when shared by all the tasks. The word "functional" is very debatable because functionality might encompas a whole lot of other things including hubexec, tasking, threading, bigger stacks/AUX, memory accesses, REP loops, multipliers, register remapping etc etc etc. All of which the P2 has over the P1.
I would say, faster but less deterministic and smaller size. The word "functional" is very debatable because functionality might encompas a whole lot of other things including hubexec, tasking, bigger stacks/AUX, memory accesses, REP loops, multipliers, register remapping etc etc etc. All of which the P2 has over the P1.
But each hardware thread must either be identical, or fit in 128 longs. That's just too inflexible.
Mixing up P1 and PII style COGS is a total nightmare of an idea.
Exactly! Two different version of PASM, two different Spin compilers, two different code generators for C or any other high level language. If the P2 COG was a strict superset of the P1 then I would say that mixing could be a good idea. However, it's sufficiently different that I think it would be confusing to have both on the same chip.
Mixing up P1 and PII style COGs introduces a nightmare of software management.
No longer can I grab any object and expect it to run anywhere. Definitely if PASM is involved. Now I have to keep the two instruction sets straight in my head.
This could probably papered over to some extent for users of high level languages, Spin and C. Who want's to be writing the code to sort that mess out at compile time?
All in all I think it would be easier to deal with spreading tasks over 4 PII style COGs and their threads rather than a mixed bag of processors.
I would go for a mixed mode device if one of the nodes was a full up Linux capable ARM SoC that happened to have a bunch of COGs as peripherals.
. If the P2 COG was a strict superset of the P1 then I would say that mixing could be a good idea.
That was the direction I suggested above, to help manage tools issues, which I admit are there.
This uses SW to solve the HW problem, of 180nm not supporting 8 P2 COGS
That, and have the P1S (S for Subset Compatible) have an illegal opcode trap.
jmg, "Engineering is the art of making what you need, from what you can get."
No doubt. I'm not sue which solution to which problem you are promoting with that statement.
What I need is a vast fabric that I can throw compute tasks at with out spending most of my time worrying about the low level details of where those tasks are or what their machine code looks or how they reach my pins, etc etc.
Seems I can get some of that in a future Propeller with P1 or PII style COGs. With various tradeoffs between the two.
That was the direction I suggested above, to help manage tools issues, which I admit are there.
This uses SW to solve the HW problem, of 180nm not supporting 8 P2 COGS
That, and have the P1S (S for Subset Compatible) have an illegal opcode trap.
An "illegal opcode trap"? You mean like an interrupt? Requiring an interrupt processing routine?
Don't you think this is all getting just a little silly?
Mixing up P1 and PII style COGs introduces a nightmare of software management.
No longer can I grab any object and expect it to run anywhere. Definitely if PASM is involved. Now I have to keep the two instruction sets straight in my head.
See the other Posts, the P1 here is P1S (S for Subset Compatible), so code written for that, can run anywhere.
Assemblers already have Target-Controls, that spit errors on unsupported opcodes, and you will know when you start, if you are doing a low-level driver, or a library that needs all P2 opcodes.
Sure, it takes some management, but it does solve the 180nm problem of not accepting 8 P2 COGS.
[COLOR=#333333]...have an illegal opcode trap.[/COLOR]
Did you just introduce an interrupt into the Propeller architecture?
How does that TRAP make my code work better?
Many micros do this already, it is simply a means to go to some memory location, on encountering an illegal opcode.
Hardly complicated, or hard to understand, and no, not an interrupt. In a P1S it would be a Jump.
What happens next, is up to the user, but this gives a simple and optional method to manage object level 'oops' differences.
Of course, Software tools could do this checking upstream too, easily enough.
It knows where the final image will be loaded, and can check for illegal opcodes in the binary, again not a brick wall.
Many micros do this already, it is simply a means to go to some memory location, on encountering an illegal opcode.
Hardly complicated, or hard to understand, and no, not an interrupt. In a P1S it would be a Jump.
What happens next, is up to the user, but this gives a simple and optional method to manage object level 'oops' differences.
Of course, Software tools could do this checking upstream too, easily enough.
It knows where the final image will be loaded, and can check for illegal opcodes in the binary, again not a brick wall.
I'm sorry, jmg - this is just getting too silly to continue responding to.
The PROBLEM is kids is most of us want BOTH. There's only one practical way to have both.
(as I see it, anyway, I'm not speaking for anyone but myself)
There is existing technology for a PaaXbb with some set of features built from off the shelf or near off the shelf pieces.
THIS STEP NEEDS TO BECOME A MOSTLY CLOSED PROCESS
Chip needs to freeze the vision on this chip and put it together in the lab. If it needs to be tested, then when it is finished to the announced spec, he release an FPGA image to be tested. Bugs get fixed, NO FEATURES ARE ADDED.
Chip and Ken come up with dates for the first shuttle of the PaaXbb and commit to it. We don't need to know that shuttle date,. We are just given a testing deadline if we're given anything.
PzzXbb goes off to shuttle at some point and comes back as packaged chips ready to test and possible ready to share with some of the community. The production runs starts, Parallax announce General Availability dates and the PaaXbb becomes a real Parallax product BUILT TO THE SPECS ORIGINALLY ANNOUNCED.
When Chip has had time to recover and enjoy life, liberty and the pursuit of happiness, hunting of the P2 resumes and everyone has their new PaaXbb chips in hand and is happily distracted working on those. The process becomes open and transparent again and the P2 goes to shuttle with a smaller process when Parallax can afford it.At some time, we get real P2 chips that we can order.
We end up getting both, with a few sacrifices being made by EVERYONE along the way. Hopefully a quicker release on the PaaXbb which has a design that was fully specified up front and a magnificent P2 that we've had to wait even longer for.
This goes back to whatever Chip sees fit to put into the PaaXbb and nothing more. The key to success is to FREEZE the design Chip comes up with and send it off and get it done as Chip and Ken see fit. Any feature creeping on the PaaXbb dooms it to failure and a warm death in a large process. I believe, there's been more than enough input provide for Chip and Ken to make sound decisions.
I would buy into this plan (which I think is how Ross' poll thread started out) and would help fund both efforts (P2 hopefully through purchases of P1 and PaaXbb and other Parallax products).
The PROBLEM is kids is most of us want BOTH. There's only one practical way to have both.
(as I see it, anyway, I'm not speaking for anyone but myself)
There is existing technology for a PaaXbb with some set of features built from off the shelf or near off the shelf pieces.
THIS STEP NEEDS TO BECOME A MOSTLY CLOSED PROCESS
Chip needs to freeze the vision on this chip and put it together in the lab. If it needs to be tested, then when it is finished to the announced spec, he release an FPGA image to be tested. Bugs get fixed, NO FEATURES ARE ADDED.
Chip and Ken come up with dates for the first shuttle of the PaaXbb and commit to it. We don't need to know that shuttle date,. We are just given a testing deadline if we're given anything.
PzzXbb goes off to shuttle at some point and comes back as packaged chips ready to test and possible ready to share with some of the community. The production runs starts, Parallax announce General Availability dates and the PaaXbb becomes a real Parallax product BUILT TO THE SPECS ORIGINALLY ANNOUNCED.
When Chip has had time to recover and enjoy life, liberty and the pursuit of happiness, hunting of the P2 resumes and everyone has their new PaaXbb chips in hand and is happily distracted working on those. The process becomes open and transparent again and the P2 goes to shuttle with a smaller process when Parallax can afford it.At some time, we get real P2 chips that we can order.
We end up getting both, with a few sacrifices being made by EVERYONE along the way. Hopefully a quicker release on the PaaXbb which has a design that was fully specified up front and a magnificent P2 that we've had to wait even longer for.
This goes back to whatever Chip sees fit to put into the PaaXbb and nothing more. The key to success is to FREEZE the design Chip comes up with and send it off and get it done as Chip and Ken see fit. Any feature creeping on the PaaXbb dooms it to failure and a warm death in a large process. I believe, there's been more than enough input provide for Chip and Ken to make sound decisions.
I would buy into this plan (which I think is how Ross' poll thread started out) and would help fund both efforts (P2 hopefully through purchases of P1 and PaaXbb and other Parallax products).
I hope nobody is offended!
I'm very offended! You obviously didn't hit the opium den this morning thus giving you a distinct cognitive advantage over some of us, that is just downright rude and unfair!
Comments
"Engineering is the art of making what you need, from what you can get."
Thansk Chip, that can never be unseen now, point taken haha
Perfect picture!!!!!
Which is probably why the proposal on the table is for 16 x P1 COGs.
"Pragmatic, adj, dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations."
Faster, but less functional.
It's much like treating the P2 cog like a FPU, or GPU and the P1 COGs like a uC ?
Meanwhile, see how much common-stuff it is possible to pull off a P2 COG to shrink it to a object-compatible subset.
I like your shrink-via-shared-common 'big ops' logic idea.
One method to improve tools and learning would be to clone only P1 opcodes, in P2 binary subset, that would at least allow a P1S (S for Subset Compatible) object to run in a P2 host.
That shifts 'different' to 'subset' which is easier to learn. Simple Illegal opcode coverage could catch the other direction.
That's true.
I would say, faster but less deterministic and smaller size COG RAM when shared by all the tasks. The word "functional" is very debatable because functionality might encompas a whole lot of other things including hubexec, tasking, threading, bigger stacks/AUX, memory accesses, REP loops, multipliers, register remapping etc etc etc. All of which the P2 has over the P1.
If you mean a current physical P1, yes.
But each hardware thread must either be identical, or fit in 128 longs. That's just too inflexible.
Ross.
No longer can I grab any object and expect it to run anywhere. Definitely if PASM is involved. Now I have to keep the two instruction sets straight in my head.
This could probably papered over to some extent for users of high level languages, Spin and C. Who want's to be writing the code to sort that mess out at compile time?
All in all I think it would be easier to deal with spreading tasks over 4 PII style COGs and their threads rather than a mixed bag of processors.
I would go for a mixed mode device if one of the nodes was a full up Linux capable ARM SoC that happened to have a bunch of COGs as peripherals.
That was the direction I suggested above, to help manage tools issues, which I admit are there.
This uses SW to solve the HW problem, of 180nm not supporting 8 P2 COGS
That, and have the P1S (S for Subset Compatible) have an illegal opcode trap.
"Engineering is the art of making what you need, from what you can get."
No doubt. I'm not sue which solution to which problem you are promoting with that statement.
What I need is a vast fabric that I can throw compute tasks at with out spending most of my time worrying about the low level details of where those tasks are or what their machine code looks or how they reach my pins, etc etc.
Seems I can get some of that in a future Propeller with P1 or PII style COGs. With various tradeoffs between the two.
An "illegal opcode trap"? You mean like an interrupt? Requiring an interrupt processing routine?
Don't you think this is all getting just a little silly?
Ross.
How does that TRAP make my code work better?
See the other Posts, the P1 here is P1S (S for Subset Compatible), so code written for that, can run anywhere.
Assemblers already have Target-Controls, that spit errors on unsupported opcodes, and you will know when you start, if you are doing a low-level driver, or a library that needs all P2 opcodes.
Sure, it takes some management, but it does solve the 180nm problem of not accepting 8 P2 COGS.
Oooh, I like that idea. Every time I want an interrupt I hand-code an illegal opcode in there. Z80 'RSTs' anyone?
Many micros do this already, it is simply a means to go to some memory location, on encountering an illegal opcode.
Hardly complicated, or hard to understand, and no, not an interrupt. In a P1S it would be a Jump.
What happens next, is up to the user, but this gives a simple and optional method to manage object level 'oops' differences.
Of course, Software tools could do this checking upstream too, easily enough.
It knows where the final image will be loaded, and can check for illegal opcodes in the binary, again not a brick wall.
The only trouble with that is that the P2 instruction set is so big that there are no illegal opcodes!
Ross.
I'm sorry, jmg - this is just getting too silly to continue responding to.
Ross.
That's fine by me. I give a working solution, and you have... ?
That did not answer my question "How does that TRAP make my code work better"?
Brian,
I do hope there is an implied smiley at the end of that statement.
(as I see it, anyway, I'm not speaking for anyone but myself)
There is existing technology for a PaaXbb with some set of features built from off the shelf or near off the shelf pieces.
THIS STEP NEEDS TO BECOME A MOSTLY CLOSED PROCESS
Chip needs to freeze the vision on this chip and put it together in the lab. If it needs to be tested, then when it is finished to the announced spec, he release an FPGA image to be tested. Bugs get fixed, NO FEATURES ARE ADDED.
Chip and Ken come up with dates for the first shuttle of the PaaXbb and commit to it. We don't need to know that shuttle date,. We are just given a testing deadline if we're given anything.
PzzXbb goes off to shuttle at some point and comes back as packaged chips ready to test and possible ready to share with some of the community. The production runs starts, Parallax announce General Availability dates and the PaaXbb becomes a real Parallax product BUILT TO THE SPECS ORIGINALLY ANNOUNCED.
When Chip has had time to recover and enjoy life, liberty and the pursuit of happiness, hunting of the P2 resumes and everyone has their new PaaXbb chips in hand and is happily distracted working on those. The process becomes open and transparent again and the P2 goes to shuttle with a smaller process when Parallax can afford it.At some time, we get real P2 chips that we can order.
We end up getting both, with a few sacrifices being made by EVERYONE along the way. Hopefully a quicker release on the PaaXbb which has a design that was fully specified up front and a magnificent P2 that we've had to wait even longer for.
This goes back to whatever Chip sees fit to put into the PaaXbb and nothing more. The key to success is to FREEZE the design Chip comes up with and send it off and get it done as Chip and Ken see fit. Any feature creeping on the PaaXbb dooms it to failure and a warm death in a large process. I believe, there's been more than enough input provide for Chip and Ken to make sound decisions.
I would buy into this plan (which I think is how Ross' poll thread started out) and would help fund both efforts (P2 hopefully through purchases of P1 and PaaXbb and other Parallax products).
I hope nobody is offended!
I'm very offended! You obviously didn't hit the opium den this morning thus giving you a distinct cognitive advantage over some of us, that is just downright rude and unfair!
C.W.