Yes, you are right Brian. Let's move forward. I was just wondering how this would break all the old OBEX code.
I know there are many smarter than me that will show us the way.
Maybe Ken will start a new Open Propeller Project to port all of the old OBEX code to the new chip. I guess the first step would be to make a prioritized list of objects so we port the most important ones first.
Who needs OBEX when we have Forth? I am sure Peter J, Dave Hein, and Sal Sanci will love to get this working post haste so that the rest of you can figure out how to fully exploit P2ASM.
Exactly. Chip really needs to evaluate the cost - in terms of heat, in terms of mux'ing the CPU to death, and in terms of silicon real estate. Phil has been the most strident voice of all in telling Chip that all such decisions are ultimately Chip's alone.
Chip asked Phil to provide info on counter use cases.
One possibility might be to factor the counters out of being 'part of' the COG, not going as far as making them a HUB resource like the CORDIC or a SMART IO.
Similar to the SYSOP instruction there could be a COGOP to access the counter registers. The Counter Modules could be made available on a subset of the COGs, say maybe 4 or 8 of them.
Who needs OBEX when we have Forth? I am sure Peter J, Dave Hein, and Sal Sanci will love to get this working post haste so that the rest of you can figure out how to fully exploit P2ASM.
I see. So nobody want to use the native tongue of the Propeller? ;-)
How many of those won't work with the new pin-based counters?
Phil has used the counters in some amazing ways. I think the question is exactly "how many of his uses of the counters won't work" and that is certainly a valid concern and why he posted his collection of code. It would nice to see Phil's (and others) creative counter use continue with the new chip. But there are still questions as to what is being pushed to the pins, will it be able to handle the tricks Phil has come up with or will there still need to be some core counter functions in the COG. It would be a shame to limit the growth of some truly interesting use cases for the counters if they can be carried forward (with complete functionality) in some form to the P16x32 architecture. If it can all be pushed to the pins, great, if there still needs to be a counter, I think that is certainly worth investigating. If it just can't be done due to the design changes well, that's a con of the new chip that just needs to be accepted along with the lost use cases.
I see. So nobody want to use the native tongue of the Propeller? ;-)
It is not that I don't want to use the forth-coming P2ASM, I just haven't yet mastered PASM.
I am sure that there will lots of brighter people jumping to do very clever things as the contrast with mainstream processors offers a well spring of new insights.
Forth has a long history of being useful for an early chip language. One gets to poke around interactively and verify if the documents are right or not.
Who needs OBEX when we have Forth? I am sure Peter J, Dave Hein, and Sal Sanci will love to get this working post haste so that the rest of you can figure out how to fully exploit P2ASM.
Loopy, I think most of us need the OBEX. If you really want to kill P1+ just tell everybody they have to program it in Forth. I do plan on porting pfth or Fast to the P1+, but I view that as more of an academic exercise. The real work will be done in Spin, C and PASM.
It is not that I don't want to use the forth-coming P2ASM, I just haven't yet mastered PASM.
I am sure that there will lots of brighter people jumping to do very clever things as the contrast with mainstream processors offers a well spring of new insights.
It's going to be like the current PASM with some extra fun bells and whistles. At the basic level, it will be like the P1 (Except for a few architecture mandated differences). The core instructions will be the same, you still have a COG that has 496 longs to hold program code and data, there will still be similar interfaces between Spin and PASM to get a PASM COG started and pass data. Even the radically different P2 (ok, what the heck do we call that one now?) was still programmable at the PASM level like a P1.
Just because a feature is there does not mean you HAVE to use it. In most cases, you can just ignore the new stuff.
I see. So nobody want to use the native tongue of the Propeller? ;-)
While I spend more time programming to prop1 with C these days (OK, I've only had a few hours to "play" over the last 6 months) but I can't imagine not having spin!
PASSCNT is only useful for tasks, as a single-task program can just do a WAITCNT with perfect timing granularity. Do you still think it's needed? It can be done discretely, but it's 3-4 instructions.
We need to do some simple SETZC, maybe a PICKZC D/#,S/#, as it's the ultimate flag tweaker.
Chip,
You got rid of ADDS, but kept ADDX and SUBX. I think we need ADDS more than the X variants. Signed addition (and thus subtraction because it's signed) is way more useful than ADDX/SUBX in my opinion.
ADDS and ADD yield the same D result, right? The only difference is in the C flag. For ADDS, C=1 indicates a signed overflow. Is this your understanding, too?
You pointed out that cog is a term that bonds the community. I agree, but we also want the community to be much larger. In fact, it has to be bigger to make this business viable. While there are many reasons it's not a larger community, some of them are small, and this is one of them. We've spent much time in China promoting the Propeller in education and we've made some headway. Several universities in Shaanxi province have taken it on. But English is a relatively new language, especially to the older educators (but the students are now fluent). We've used every possible presentation approach, and our best results are when we get to engage people with hardware in front of them and code on the projection screen. However, even in this very favorable environment with impressive high-level demos, the choice of words affects the amount of retention and interest. As you present the terms - cog, Spin, hub RAM - the interest can fade. But if you replace them with core, Propeller programming language, and RAM, the barriers are lower because they already know these terms. And, at the right time, after they've accepted what they're seeing, we use Propeller-specific terms and get better results.
The process of introducing Propeller-specific terms is easier in Europe, and of course even easier here at home.
You mentioned that perhaps we should use "core" for marketing but leave the term "cog" in place. That's basically what we're doing, so it's good to hear your thoughts.
But I still think we should take it a step further: standardize, make it easier to adopt. That's why I propose "core".
Of course, with instructions based on the word COG this is difficult to do and Chip would need to accept bigger changes. We don't have complete P1 backward-compatibility anyway.
We have made some mistakes in the past and I don't care to see us repeat them again. One of the bigger ones was not having C support right out the gate.
SmartIO is a great term. I don't know what it means yet, but it's somewhat self-explanatory. Thanks to Sapieha.
Ken Gracey
In my business life, I've had to be both the Chip AND the Ken Gracey so when the 16/32 cogs question came up where I got the impression that 32 cogs would not be a big deal, I immediately saw the marketing appeal right there.
Cogs, cores? I say ditch them both and use the more universally understandable verbiage of "16 Parallel CPUs on one chip"...it's true, right?
In my business life, I've had to be both the Chip AND the Ken Gracey so when the 16/32 cogs question came up where I got the impression that 32 cogs would not be a big deal, I immediately saw the marketing appeal right there.
Cogs, cores? I say ditch them both and use the more universally understandable verbiage of "16 Parallel CPUs on one chip"...it's true, right?
Strictly speaking, a CPU has no memory, it attaches to external memory.
Since a COG has it's own memory it can execute instructions from it is a micro-controller in it's own right. Then you get "16 parallel 32-bit micro-controllers on a single chip with shared access to 512Kb of memory and 64 Smart I/O Pins."
ADDS and ADD yield the same D result, right? The only difference is in the C flag. For ADDS, C=1 indicates a signed overflow. Is this your understanding, too?
Yeah, and thinking about things further, maybe we should just keep all the ADD/SUB variants? Or at least keep ADD/ADDS/ADDX/SUB/SUBS/SUBX.
ADDS and ADD yield the same D result, right? The only difference is in the C flag. For ADDS, C=1 indicates a signed overflow. Is this your understanding, too?
Yes that's the difference. But it is hard to get the C flag set at the $7FFFFFFF -> $80000000 boundary without ADDS. But it is easy to emulate ADDX with:
Chip,
I still think we can leave out the ASBNEG/ADDABS/SUBABS ones. They are rarely if ever used and easily replicated with the two instructions they comprise.
If there is instruction space available, then keep all the ADD/SUB variants, but if you need to drop some, the ???X versions should be the first to go.
Ariba,
Thanks for showing how easy it is to do ADDX. For the FSRW case, they probably only need the if_c ADD D,#1 part.
A thought on the issue of CTR's (which I agree are needed) and the PLL's -- is there any possibility of fixing the feedback problem that causes the PLL's to jitter so that they could be made to output a spectrally clean radio signal?
For me NEGC, NEGNC, NEGZ, NEGNZ are instructions that are not often used and can be replaced with:
if_c NEG D,S
if_nz NEG D,S ...etc
That does the same if D and S point to the same register, otherwise it needs an additional MOV D,S before.
Another idea to reduce the instructions: It may be enough to use only PTRB as a call-stack pointer.
Then all the CALLA #, CALLA @, CALLA D, RETA, can be removed. I would keep POPA and PUSHA so that PTRA can still be used for a Datastack.
Will all the WAITxxx and MSGINA/B instruction behave like in the Prop2 in task mode (jump to itself)? Are tasks really necessary when we have 16 cogs?
Chip asked Phil to provide info on counter use cases.
I was going off this mention by Chip:
I wonder the same things, too, but Phil Pilgrim is absolutely adamant that we must keep them.
There is a smidge of hypocrisy here. How many times has Phil insisted that either Chip should decide everything or else commercial users should decide everything?
Comments
Yes, you are right Brian. Let's move forward. I was just wondering how this would break all the old OBEX code.
I know there are many smarter than me that will show us the way.
Loopy,
You been in the opium den?
News is two days old.
Chip has already promised me that we will use .SPIN2 or something as the Propeller2 file extension (whatever the name is).
Nothing gets broken in the OBEX because there is no SPIN2 source files there yet.
Chip asked Phil to provide info on counter use cases.
One possibility might be to factor the counters out of being 'part of' the COG, not going as far as making them a HUB resource like the CORDIC or a SMART IO.
Similar to the SYSOP instruction there could be a COGOP to access the counter registers. The Counter Modules could be made available on a subset of the COGs, say maybe 4 or 8 of them.
C.W.
Phil has used the counters in some amazing ways. I think the question is exactly "how many of his uses of the counters won't work" and that is certainly a valid concern and why he posted his collection of code. It would nice to see Phil's (and others) creative counter use continue with the new chip. But there are still questions as to what is being pushed to the pins, will it be able to handle the tricks Phil has come up with or will there still need to be some core counter functions in the COG. It would be a shame to limit the growth of some truly interesting use cases for the counters if they can be carried forward (with complete functionality) in some form to the P16x32 architecture. If it can all be pushed to the pins, great, if there still needs to be a counter, I think that is certainly worth investigating. If it just can't be done due to the design changes well, that's a con of the new chip that just needs to be accepted along with the lost use cases.
It is not that I don't want to use the forth-coming P2ASM, I just haven't yet mastered PASM.
I am sure that there will lots of brighter people jumping to do very clever things as the contrast with mainstream processors offers a well spring of new insights.
Forth has a long history of being useful for an early chip language. One gets to poke around interactively and verify if the documents are right or not.
It's going to be like the current PASM with some extra fun bells and whistles. At the basic level, it will be like the P1 (Except for a few architecture mandated differences). The core instructions will be the same, you still have a COG that has 496 longs to hold program code and data, there will still be similar interfaces between Spin and PASM to get a PASM COG started and pass data. Even the radically different P2 (ok, what the heck do we call that one now?) was still programmable at the PASM level like a P1.
Just because a feature is there does not mean you HAVE to use it. In most cases, you can just ignore the new stuff.
While I spend more time programming to prop1 with C these days (OK, I've only had a few hours to "play" over the last 6 months) but I can't imagine not having spin!
You have lots to do.
Ken Gracey
PASSCNT is only useful for tasks, as a single-task program can just do a WAITCNT with perfect timing granularity. Do you still think it's needed? It can be done discretely, but it's 3-4 instructions.
We need to do some simple SETZC, maybe a PICKZC D/#,S/#, as it's the ultimate flag tweaker.
ADDS and ADD yield the same D result, right? The only difference is in the C flag. For ADDS, C=1 indicates a signed overflow. Is this your understanding, too?
In my business life, I've had to be both the Chip AND the Ken Gracey so when the 16/32 cogs question came up where I got the impression that 32 cogs would not be a big deal, I immediately saw the marketing appeal right there.
Cogs, cores? I say ditch them both and use the more universally understandable verbiage of "16 Parallel CPUs on one chip"...it's true, right?
Strictly speaking, a CPU has no memory, it attaches to external memory.
Since a COG has it's own memory it can execute instructions from it is a micro-controller in it's own right. Then you get "16 parallel 32-bit micro-controllers on a single chip with shared access to 512Kb of memory and 64 Smart I/O Pins."
That is an instruction on the IBM PowerPC (Enforce In-Order Execution of I/O) - may be trademarked?
Yeah, and thinking about things further, maybe we should just keep all the ADD/SUB variants? Or at least keep ADD/ADDS/ADDX/SUB/SUBS/SUBX.
That's a good description that punches through the ambiguity of what "cores" might mean to people. By some industry metric, we could claim 64 cores!
They are free. They just take some opcode space, which we have. What about ABSNEG/ADDABS/SUBABS/etc.?
Yes that's the difference. But it is hard to get the C flag set at the $7FFFFFFF -> $80000000 boundary without ADDS. But it is easy to emulate ADDX with:
if_c ADD D,#1 ADD D,SAndy
I still think we can leave out the ASBNEG/ADDABS/SUBABS ones. They are rarely if ever used and easily replicated with the two instructions they comprise.
If there is instruction space available, then keep all the ADD/SUB variants, but if you need to drop some, the ???X versions should be the first to go.
Ariba,
Thanks for showing how easy it is to do ADDX. For the FSRW case, they probably only need the if_c ADD D,#1 part.
if_c NEG D,S
if_nz NEG D,S ...etc
That does the same if D and S point to the same register, otherwise it needs an additional MOV D,S before.
Another idea to reduce the instructions: It may be enough to use only PTRB as a call-stack pointer.
Then all the CALLA #, CALLA @, CALLA D, RETA, can be removed. I would keep POPA and PUSHA so that PTRA can still be used for a Datastack.
Will all the WAITxxx and MSGINA/B instruction behave like in the Prop2 in task mode (jump to itself)? Are tasks really necessary when we have 16 cogs?
Andy
I was going off this mention by Chip:
There is a smidge of hypocrisy here. How many times has Phil insisted that either Chip should decide everything or else commercial users should decide everything?
The FSRW code can use: RCL D,#1 like all the other similar SPI routines.
Andy