David, the premise of this thread is that you have to start with the P1, and then add P2 features in a piecemeal way until you get close to a P2. You can't just start with a P2. That would make too much sense.
David, the premise of this thread is that you have to start with the P1, and then add P2 features in a piecemeal way until you get close to a P2. You can't just start with a P2. That would make too much sense.
I suppose that's true but it takes all of the fun out of it! :-)
In any case, hubexec will require a way to load 32 bit constants so I think something like AUGS will be needed and if AUGS is added it can be used to form hub addresses at the cost of an extra long. I admit that that is a huge cost but it does eliminate the need to find a way to shoehorn 17 bit immediate addresses into CALL and JMP.
Didn't someone suggest using the P2 instruction encodings for the enhanced P1? That would allow AUGS to be brought over easily. The 17 bit CALL and JMP are a bigger problem though since the P2 only has 256k of hub memory which only requires 16 bits. As I mentioned earlier, you could just use a normal CALL and JMP preceeded by an AUGS instruction but that makes hub CALL and JMP take two longs. Again, this is no worse than LMM on the original Propeller.
Yes, using the P2 instruction encodings for the enhanced P1 is an obvious choice, as soon as the enhanced P1 diverges from the classic P1 in any way.
It is also the obvious choice in any mixing COGS solution, as they are then binary (subset) compatible.
David, the premise of this thread is that you have to start with the P1, and then add P2 features in a piecemeal way until you get close to a P2. You can't just start with a P2. That would make too much sense.
Well it isn't.
the voting of this thread was overwhelmingly to keep the P1 cogs and do NOT use P2 cogs/instructions.
The OBEX thing. Throw in existing objects and done. More speed, more cogs, more pins. SAME software.
No Hubexec/Cache/Wides/Pointers/whatever. Read the thread and read the counts.
That is the product people voted for. NOT a castrated P2 beta with not yet to be defined opcodes and features.
When you guys are done "designing" the P1+ you're going to end up with something slightly less than a P2. So why not start with the P2, and remove just enough features to get it down to 2 Watts? I think you'd get there a lot quicker than adding features to P1.
Sure - That's effectively what the suggestion of using P2 opcode encodings does.
It also makes the 'P1+' binary compatible with any P2.
If we ever get to that point, so would I. Lots of talk on these forums - let's see how people vote with their wallets!
Ross.
Why not do it now?
As stated above I would be willing to put $1000-$2000 on the block for some Tortillas and a nice weekend at Parallax.
Just let all those people who have a opinion on how it is to be done decide if they would still like to do that if their own money is involved.
No refund, no product credit for future times. Nothing. Some Tortillas from Chip and a good feeling to have done the right thing.
If more people pay in for the P1 version - so is it.
If more people pay for the P2 version - so is it.
Else Parallax can do what them want with the money.
Like Politics works. (not just America, at least Germany is no difference there).
Just to be clear here - this thread is about the P16X32B, and the other chip defined by Chip in post #1. He didn't give the other one an "official" name, but I now will - I'm going to call it the P32X32B (I will amend the first post to reflect this). These are P1 variants, not P2 subsets. They may end up with some P2 enhancements in them, but that is not the point of this thread. Cluso has started another thread for discussing such hybrids (which he calls the P16+X32B) here.
This thread is for saying Yes or No to whether you want to see something that could reasonably fall into the description Chip has given of the P16X32B or P32X32B. Feel free to discuss related issues, but the main purpose of this thread is to give Chip the input he asked for on whether we could achieve consensus on such a beast.
I don't know how to respond to such a close-minded comment. I guess we'll see where the P1+ is in a few days.
Just trying to keep this thread on track. You have registered your vote, and I am happy to for you to keep contributing other comments, but there are other threads for discussing the P2 and P1/P2 Hybrids.
Didn't someone suggest using the P2 instruction encodings for the enhanced P1? That would allow AUGS to be brought over easily. The 17 bit CALL and JMP are a bigger problem though since the P2 only has 256k of hub memory which only requires 16 bits. As I mentioned earlier, you could just use a normal CALL and JMP preceeded by an AUGS instruction but that makes hub CALL and JMP take two longs. Again, this is no worse than LMM on the original Propeller.
David,
FYI Changing the instruction opcodes is quite likely to be simple, but bringing P2 instructions over is not going to be simple. The P2 pipeline is 4 stages whereas the P1+ is 2 stages.But the concepts of what the instructions do will certainly make it easier.
Not really. Here is an extract from Chip's original reaction to the P2 problems that caused this whole thread (emphasis mine):
Pare down the design, jettisoning all kids of features, like hub exec,
He then proposed the alternatives (quoted in post #1) which do not include extensions such as the ones you are now proposing. If Chip decides to add them later, fine - but they were not included in the original scope, and may turn out not to be practical.
So I am not being inconsistent. Quite the opposite.
So Bill's vote is No.
But if some items get added (he listed them) he would change his vote. Seems reasonable. He just qualified why he voted no.
Since there are so few who voted no, perhaps this is a good addition to your summary of the no votes as it helps the PnnX32B cause.
If these enhanced P1 considerations continue in earnest (with lots of good ideas and support), and Chip/Ken/Parallax commit in that direction (even while continuing the work on the P2), then we might need a new general thread for the P16X32B or P32X32B. I don't know if the time for that is now, though. But if (and when?) Parallax commits, then a new general thread would be helpful to kind of isolate things from the P2 design considerations and avoid some of the "clutter." I admit that it has been convenient to keep them together so far, but a fork might be needed pretty soon. And one might take it as a sign that things are not really serious (yet) until the discussion is forked. Meanwhile, let the discussion continue.
Reading these posts has kind of been a hobby in and of itself over the last few years, but with the explosion of posts over the last week, I've actually done some skim reading recently (I know! Not really a full-fledged follower anymore, ha-ha). I actually managed to keep up with just about all of the P2 changes last fall, but I'm starting to get lazy. A P16X32B/P32X32B general forum might help me know how to direct my attention (or how to divide it up). An enhanced P1 is enough of a "new animal" to warrant its on species designation (a new general forum).
There has been a request to add people's $$$ figures for funding to this thread. I think it is a bit premature, but I would do that if Parallax thinks they might consider some form of crowd-funding, and (more importantly) proposes their "preferred" funding model.
If these enhanced P1 considerations continue in earnest (with lots of good ideas and support), and Chip/Ken/Parallax commit in that direction (even while continuing the work on the P2), then we might need a new general thread for the P16X32B or P32X32B. I don't know if the time for that is now, though. But if (and when?) Parallax commits, then a new general thread would be helpful ...
Absolutely. If Parallax come up with a new and more concrete proposal, I will probably close this thread. That's actually the purpose of this thread - to allow them to judge the level of consensus for such a proposal.
But I don't think we help their decision-making process by filling threads like this with so many alternative designs that it becomes difficult to figure out exactly who supports what.
David,
FYI Changing the instruction opcodes is quite likely to be simple, but bringing P2 instructions over is not going to be simple. The P2 pipeline is 4 stages whereas the P1+ is 2 stages.But the concepts of what the instructions do will certainly make it easier.
I'm sure that is true for some instructions but maybe not all. Anyway, Chip said he had done some research into adding hubexec mode to P1 and it sounded like he thought it was doable. I guess it's up to him to decide what can be done and what can't. There is, of course, also the question of the risk associated with larger changes. Chip and Ken will have to sort this out and decide which approach is most likely to be successful given their target audience. From what Ken says, even the enhanced P1 without hubexec will satisfy many of the needs his customers have expressed. What is probably unknown is what features are needed to attract customers that don't already use the Propeller.
While a P1+ would be a great addition to the Propeller family, and I think would be needed as a refresh to the now aging P1 design, it does not solve the core issues that lead to the P2 and thus I could not choose it over a P2 at this point.
The P1, for my type of industrial process control work, simply cannot get the job done by itself. This is a function of limited RAM (hub and cog), limited I/O count and more importantly limited Video/external RAM. The video that a P1 (or P1+) can do is just not good enough for a commercial product. After all when nearly everyone's phones are rocking 800x600 minimum how do you not get laughed at with P1 grade video? Thus even if the P1+ can do the core RT control functions you have to use some other micro.controller/processor in your design in order to finish the product.
There is also the fact that while the P1 instruction set is wonderfully simple it is missing a LOT of performance and quality of life instructions that its competitors have. Just look at the hoops we have to jump through just to read/set a flag bit or group of I/O pins. Even the SX chip had individual bit control instructions!
A P2 would open up a new range of markets for Parallax while a P1+ would simply let them keep up in their existing ones.
Based on the described P1+ that leaves my vote as NO for P1+ before the P2 but YES for being done after.
I would prefer a scaled back P2. We don't need Analog on every pin, we can go with either 4 cogs, with more memory, as is (well within our power envelope) or 8 cogs that leave in hubexec but get rid of extra features to get the power down. I would really like to see a hybrid (2xP2 +16xP1 @ 96 I/O). The problem with that is not that people would accept a dual core configuration, ARM is bragging about their chips with that feature, it is that ARM IS bragging about that feature so you can bet they have a PATENT on it.
The P1, for my type of industrial process control work, simply cannot get the job done by itself. This is a function of limited RAM (hub and cog), limited I/O count and more importantly limited Video/external RAM. The video that a P1 (or P1+) can do is just not good enough for a commercial product. After all when nearly everyone's phones are rocking 800x600 minimum how do you not get laughed at with P1 grade video? Thus even if the P1+ can do the core RT control functions you have to use some other micro.controller/processor in your design in order to finish the product.
I have recorded your No vote, but I think your post indicates that you may be considering the Propeller for the wrong type of application. Neither the P1 nor the P2 would ever be suitable for a phone. That is a very specialized market and not at all the market they are designed to cater to.
The fact that you even consider them for this type of application is a testament to their versatility, and not a criticism of their limitations.
I believe he was thinking of removing it so he could remove the 4 line 8 long icache, and the 1 line 8 long dcache - all those flipflops.
The "new" "simple" hubexec I proposed can work without those caches, as the slot assignment table allows assigning more hub slots... so it can be much faster than LMM without a cache (and those flip-flops). Sorry, that may not have been evident.
Not really. Here is an extract from Chip's original reaction to the P2 problems that caused this whole thread (emphasis mine):
He then proposed the alternatives (quoted in post #1) which do not include extensions such as the ones you are now proposing. If Chip decides to add them later, fine - but they were not included in the original scope, and may turn out not to be practical.
So I am not being inconsistent. Quite the opposite.
Kerry is not making phones, but industrial HMI's, and his main point appeared to be that P1's video was not good enough for his industrial HMI usage, and that phones surpassed what the P1 can do for video. I agree with him.
FYI,
while I vote NO to doing a P16/P32 X32B *BEFORE* a 4 or 8 cog P2 as currently defined, I would like to see them afterwards, and I am totally in agreement with Kerry about why - a P1+ satisfies current P1 users, but will not likely bring new customers.
My biggest reasons are precisely the new P2 capabilities, which should bring new customers as they significantly expand the applications P2 can be used for.
I have recorded your No vote, but I think your post indicates that you may be considering the Propeller for the wrong type of application. Neither the P1 nor the P2 would ever be suitable for a phone. That is a very specialized market and not at all the market they are designed to cater to.
The fact that you even consider them for this type of application is a testament to their versatility, and not a criticism of their limitations.
I believe he was thinking of removing it so he could remove the 4 line 8 long icache, and the 1 line 8 long dcache - all those flipflops.
The "new" "simple" hubexec I proposed can work without those caches, as the slot assignment table allows assigning more hub slots... so it can be much faster than LMM without a cache (and those flip-flops). Sorry, that may not have been evident.
If Chip elects to add some kind of Hub Exec into the P16X32B or P32X32B, then I will include it in the specs at post #1 in this thread. I doubt many of the Yes votes will then turn to No votes, but I also doubt that all the No votes will suddenly become Yes votes, so it won't in the end make much difference to the degree of consensus we seem to have reached for a P16X32B.
Comments
In any case, hubexec will require a way to load 32 bit constants so I think something like AUGS will be needed and if AUGS is added it can be used to form hub addresses at the cost of an extra long. I admit that that is a huge cost but it does eliminate the need to find a way to shoehorn 17 bit immediate addresses into CALL and JMP.
The P2 is a non-starter. Which is why we have this thread.
Ross.
Yes, using the P2 instruction encodings for the enhanced P1 is an obvious choice, as soon as the enhanced P1 diverges from the classic P1 in any way.
It is also the obvious choice in any mixing COGS solution, as they are then binary (subset) compatible.
Well it isn't.
the voting of this thread was overwhelmingly to keep the P1 cogs and do NOT use P2 cogs/instructions.
The OBEX thing. Throw in existing objects and done. More speed, more cogs, more pins. SAME software.
No Hubexec/Cache/Wides/Pointers/whatever. Read the thread and read the counts.
That is the product people voted for. NOT a castrated P2 beta with not yet to be defined opcodes and features.
a P1 on steroids.
Enjoy!
Mike
Sure - That's effectively what the suggestion of using P2 opcode encodings does.
It also makes the 'P1+' binary compatible with any P2.
The 8 COG P2 has come in at 8 Watts, 180MHz 1.8V It is only this that is the non-starter.
Chip is currently testing a 4 COG P2 in OnSemi simulations. He also has a 2 Cycle small Core, but no Sim figures on that yet.
Why not do it now?
As stated above I would be willing to put $1000-$2000 on the block for some Tortillas and a nice weekend at Parallax.
Just let all those people who have a opinion on how it is to be done decide if they would still like to do that if their own money is involved.
No refund, no product credit for future times. Nothing. Some Tortillas from Chip and a good feeling to have done the right thing.
If more people pay in for the P1 version - so is it.
If more people pay for the P2 version - so is it.
Else Parallax can do what them want with the money.
Like Politics works. (not just America, at least Germany is no difference there).
Put your wallet where your opinion is.
60 people giving $1000 can finance a shuttle run.
I am in for 16 P1 cogs.
Enjoy!
Mike
Just to be clear here - this thread is about the P16X32B, and the other chip defined by Chip in post #1. He didn't give the other one an "official" name, but I now will - I'm going to call it the P32X32B (I will amend the first post to reflect this). These are P1 variants, not P2 subsets. They may end up with some P2 enhancements in them, but that is not the point of this thread. Cluso has started another thread for discussing such hybrids (which he calls the P16+X32B) here.
This thread is for saying Yes or No to whether you want to see something that could reasonably fall into the description Chip has given of the P16X32B or P32X32B. Feel free to discuss related issues, but the main purpose of this thread is to give Chip the input he asked for on whether we could achieve consensus on such a beast.
Ross.
Just trying to keep this thread on track. You have registered your vote, and I am happy to for you to keep contributing other comments, but there are other threads for discussing the P2 and P1/P2 Hybrids.
Ross.
BOTH P2 and the P32X32B variant with my flexible slot mapping plus simple hubexec, binary compatible with P1. See my other recent posts
Hi Bill,
Your preference is outside the envelope identified by Chip. Would you accept the P32X32B without the additions?
Ross.
No.
Remember, you guys asked for the things this simple change provides for trivial gate/power cost, so opposing this change is inconsistent.
FYI Changing the instruction opcodes is quite likely to be simple, but bringing P2 instructions over is not going to be simple. The P2 pipeline is 4 stages whereas the P1+ is 2 stages.But the concepts of what the instructions do will certainly make it easier.
Not really. Here is an extract from Chip's original reaction to the P2 problems that caused this whole thread (emphasis mine):
He then proposed the alternatives (quoted in post #1) which do not include extensions such as the ones you are now proposing. If Chip decides to add them later, fine - but they were not included in the original scope, and may turn out not to be practical.
So I am not being inconsistent. Quite the opposite.
Ross.
How can you be binary compatible to a not yet build chip? P2 instructions change faster then I can understand them. And are not ready at all.
However binary compatible with the P1 is quite easy. Those 86 instructions have not changed for a while.
Enjoy!
Mike
But if some items get added (he listed them) he would change his vote. Seems reasonable. He just qualified why he voted no.
Since there are so few who voted no, perhaps this is a good addition to your summary of the no votes as it helps the PnnX32B cause.
A simple Yes from me.
Reading these posts has kind of been a hobby in and of itself over the last few years, but with the explosion of posts over the last week, I've actually done some skim reading recently (I know! Not really a full-fledged follower anymore, ha-ha). I actually managed to keep up with just about all of the P2 changes last fall, but I'm starting to get lazy. A P16X32B/P32X32B general forum might help me know how to direct my attention (or how to divide it up). An enhanced P1 is enough of a "new animal" to warrant its on species designation (a new general forum).
There has been a request to add people's $$$ figures for funding to this thread. I think it is a bit premature, but I would do that if Parallax thinks they might consider some form of crowd-funding, and (more importantly) proposes their "preferred" funding model.
Ross.
Absolutely. If Parallax come up with a new and more concrete proposal, I will probably close this thread. That's actually the purpose of this thread - to allow them to judge the level of consensus for such a proposal.
But I don't think we help their decision-making process by filling threads like this with so many alternative designs that it becomes difficult to figure out exactly who supports what.
Ross.
The P1, for my type of industrial process control work, simply cannot get the job done by itself. This is a function of limited RAM (hub and cog), limited I/O count and more importantly limited Video/external RAM. The video that a P1 (or P1+) can do is just not good enough for a commercial product. After all when nearly everyone's phones are rocking 800x600 minimum how do you not get laughed at with P1 grade video? Thus even if the P1+ can do the core RT control functions you have to use some other micro.controller/processor in your design in order to finish the product.
There is also the fact that while the P1 instruction set is wonderfully simple it is missing a LOT of performance and quality of life instructions that its competitors have. Just look at the hoops we have to jump through just to read/set a flag bit or group of I/O pins. Even the SX chip had individual bit control instructions!
A P2 would open up a new range of markets for Parallax while a P1+ would simply let them keep up in their existing ones.
Based on the described P1+ that leaves my vote as NO for P1+ before the P2 but YES for being done after.
I would prefer a scaled back P2. We don't need Analog on every pin, we can go with either 4 cogs, with more memory, as is (well within our power envelope) or 8 cogs that leave in hubexec but get rid of extra features to get the power down. I would really like to see a hybrid (2xP2 +16xP1 @ 96 I/O). The problem with that is not that people would accept a dual core configuration, ARM is bragging about their chips with that feature, it is that ARM IS bragging about that feature so you can bet they have a PATENT on it.
I have recorded your No vote, but I think your post indicates that you may be considering the Propeller for the wrong type of application. Neither the P1 nor the P2 would ever be suitable for a phone. That is a very specialized market and not at all the market they are designed to cater to.
The fact that you even consider them for this type of application is a testament to their versatility, and not a criticism of their limitations.
The "new" "simple" hubexec I proposed can work without those caches, as the slot assignment table allows assigning more hub slots... so it can be much faster than LMM without a cache (and those flip-flops). Sorry, that may not have been evident.
Kerry is not making phones, but industrial HMI's, and his main point appeared to be that P1's video was not good enough for his industrial HMI usage, and that phones surpassed what the P1 can do for video. I agree with him.
FYI,
while I vote NO to doing a P16/P32 X32B *BEFORE* a 4 or 8 cog P2 as currently defined, I would like to see them afterwards, and I am totally in agreement with Kerry about why - a P1+ satisfies current P1 users, but will not likely bring new customers.
My biggest reasons are precisely the new P2 capabilities, which should bring new customers as they significantly expand the applications P2 can be used for.
And give FAR better compiler support.
If Chip elects to add some kind of Hub Exec into the P16X32B or P32X32B, then I will include it in the specs at post #1 in this thread. I doubt many of the Yes votes will then turn to No votes, but I also doubt that all the No votes will suddenly become Yes votes, so it won't in the end make much difference to the degree of consensus we seem to have reached for a P16X32B.
Ross.