Suite me. I don't actually care what it is called, as long as it is not called LMM. Anyone who examines the architecture and instruction set of this chip will realize it is not the native mode of the Propeller - rather, it is an afterthought added on later.
But by all means call it "native" in the marketing literature if that will sell more Propellers.
Ross.
I'm not sure it will look like it was added as an afterthought. If you don't know the history you might think that "COG mode" was tacked on by reserving the first few locations in the address space to allow code to be run from the registers. :-)
I think it is very interesting that after soooooo much debate over the terminology definitions concepts methods conventions etc, that there is still so much debate. When sharp minds can, after quite a few years, still not agree on much of the "core" terminology, there is time for some shift in the process. I had a client become a friend over the years. In the states, he built a company that most of you may recognize. He has 28,000 employees and I have been fortunate to be able to spend a lot of time picking his brain on how he built a company in a broader sense, in addition to how to thought in terms some basic core fundamentals of growing the company. On the broader level, he has a lot of competition. Nothing extremely better about his product, actually some others are much better than him on some levels. But, his concept for growth is to "consolidate a fragmented marketplace". He went around the country, bought a lot of smaller one-off businesses in his genre, put his name, look, and feel on it, and now generates billions yearly. He did not necessarily invent anything, nor create anything. He simple packaged up something that already existed in a better way.
As an outsider looking into to this endless debate about terminology and concepts, may I suggest you guys take an approach of looking at a broader picture versus looking deeper in the Propeller rabbit hole of it's own uniqueness. In fact, contrast and comparison is one of the core components of marketing (when there is in fact competition, some products may not have competition). The Propeller has competition. In the broader sense, you may argue that the Propeller does in fact "consolidate some fragmentation", for example, can a beginner program some of the more complex uC's? Is there off the shelf code for some of the more complex devices on the market for a beginner or advanced user? Is basis(Spin), ASM(pasm), C, and other unnamed variants available for other uC's so that multiple backgrounds can jump right in and start right away with limited hands on? Can other competitive products be hand soldered or as easily dropped in a design as quickly as a P1 (or the newer .5mm pitch coming soon)? Why does it matter if it is not called LMM if there is a term that is similar and alludes to it being usable in a like manner to LMM. All the minutia is great for internal discussion, but endless debate has not and is not producing a clear consider definition. For bigger successes, a broader, more mass appeal is needed. Nothing wrong with celebrating uniqueness when it does not impede growth and expansion, I have seen first hand many failures that were too unique. Why not PLMM, Prop LMM: similar to functionality of standard conventions of LMM, appeal to the masses, but retain some degree of uniqueness. I don't have intentions to use LMM or care what it is. What appealed to me in the beginning, and what continues to appeal to me, is the EASE of ADAPTING a SOLUTION to a PROBLEM. Which in a business sense means, taking my idea of a product, putting that idea into a working box, and selling it to someone else that finds value in it. In the end, the Propeller is solely for that purpose alone. Granted, the "working box" may be interchanged with an educational use or personal enjoyment use, but the concept still applies regarding adapting a solution to a problem, even if the problem is fun. The Propeller IS the problem solver for me. But, so many want to debate the nomenclature. If you view the problem through the lens of the "Propeller IS the solution", does that help refine the methods of explaining the Prop to the masses?
Do we need SETPTRA, SETPTRB, SETINDA, SETINDB, SETINDS, ADJINDA, ADJINDB, ADJINDS, GETPTRA, GETPTRB ?
If they are/were part of the upper registers, then couldn't we
MOV PTRx,S/# , ADD PTRx,S/# , MOV S,PTRx etc.
The only part we cannot do is SETINDS & ADJINDS in one instruction. (saves 10 instructions)
I noticed JMPRET (from P1) is missing. Should this be included for P1 compatibility?
Should the new JMP/CALL/RET instructions that use the internal 4-level stack be renamed JMPS/CALLS/RETS to avoid confusion with the old JMPRET (JMP/CALL/RET) ? Similar for PUSH/POP to be PUSHS/POPS?
Perhaps these can become mapped registers. Good idea. The reason Prop2 uses to many GET/SET instructions is that it reduces what would have been mux'ing for both D and S, not to mention register space. Ah, one issue with having things like PTRx/INDx mapped is that they auto-increment and this would probably require some data-forwarding circuitry to ensure updated copies are used for the next D and S.
Suite me. I don't actually care what it is called, as long as it is not called LMM. Anyone who examines the architecture and instruction set of this chip will realize it is not the native mode of the Propeller - rather, it is an afterthought added on later.
I'm not sure how anyone ever implied or would have gathered that LMM is the Native mode of the new chip. If so it was a big communications failure by the writer or the reader.
I'm not sure it will look like it was added as an afterthought. If you don't know the history you might think that "COG mode" was tacked on by reserving the first few locations in the address space to allow code to be run from the registers. :-)
On the surface for the entry level user, there should not be any TLA modes to worry with at all for this new chip because it theoretically has enough memory to be useful in a native (hubexec whatever) mode of operation ... just like all the other chips out there.
I can see how some kind of a compressed instruction set could be beneficial (as did the ARM folks with thumb mode), but that is a feature that the tool producer can call any TLA they like and some kind of an agreement on that is not required.
As far as cog or pasm code goes, the entry level tool can determine which compiler mode to use without burdening the simple user. Makefile users will need to understand when cog mode should be used or when pasm sections should be extracted, etc... and that is for the Makefile people to document and use, but that is not for simple users to care about.
I'm not sure how anyone ever implied or would have gathered that LMM is the Native mode of the new chip. If so it was a big communications failure by the writer or the reader.
Actually, why not?
Not "LMM" that's the technique invented by Bill Henning to allow running of Propeller instructions from RAM.
But this new PII can execute instructions from RAM anyway, without an LMM interpreter loop.
Surely that should be the default mode of operation.
The ability of the PII to execute instructions from it's own registers is weird and unique feature that can be used if you really need the performance and can live with the severe space limitation of 496 instructions.
Actually, why not?
Not "LMM" that's the technique invented by Bill Henning to allow running of Propeller instructions from RAM.
But this new PII can execute instructions from RAM anyway, without an LMM interpreter loop.
Surely that should be the default mode of operation.
The ability of the PII to execute instructions from it's own registers is weird and unique feature that can be used if you really need the performance and can live with the severe space limitation of 496 instructions.
I agree with this attitude. This allows new people to start using it in a way they are already familiar with. When they realize what can actually be done with each of the cores, and that there is no other microcontroller out there that allows them to do the same thing, they will become as convinced of the power of the chip (and its paradigm) as we all are (regardless of whether they every actually use that capability). To that end, maybe we should refer to "hub mode" as the normal mode and "cog/core mode" as "turbo mode" (or similar phrase).
Also "exactly". "That is what I call "Native" (I don't really give a flying f*** what other people call it)."
But why call it "native" it's just a processor executing code from RAM. Like all the others. They don't call it "native", why would they, that's just what they do.
Executing code from your own resisters is weird and unique though, That is what should have a different name.
The terms COG, HUB and HUBEXEC seem perfectly fine to me. Every chip manufacturer comes up with "cute" names for the components of their chips, and I don't think newbies have a problem understanding what they mean once they are defined. I think the weird rotating cog diagram is a bit confusing, but the more traditional diagram that shows multiple processors on a shared bus is quite clear. The term HUBEXEC is perfectly clear once it is stated that a cog is executing code that sits in HUB RAM. Perhaps we need to define a term, such as COGEXEC to make it clear to newbies that a cog can execute code from it's own dedicated memory without any HUB stalls.
I think that we should stay with the terms that were used in P1, and it will reduce confusion when comparing P1+ to P1.
The terms COG, HUB and HUBEXEC have no meaning at all to the big world of micro-controller users. Explaining all that is a ten minute road block that we don't need. These terms also cause the Propeller to not show up in searches when people are looking for a solution to their problems.
Yes, the weird rotating cog diagram has to go. Every multi-core chip has to access RAM some how whilst fighting with its peers. That detail does not even show on product briefs.
The term HUBEXEC is just silly. Pretty much all multi-core machines execute code from such a shared memory.
"COGEXEC" is interesting. That is a unique Propeller feature as far as I know.
But hey, we cannot call it "COGEXEC", because we have cores. Right? REGEXEC may be. Or "Turbo nutter mode"?
That sounds better, HUB needs to become simply Global/Shared RAM, pretty much like the 'big memory' on any controller.
REGister memory that can also EXECute is not something your average PIC16 user will have seen before.
"COGEXEC" is interesting. That is a unique Propeller feature as far as I know.
But hey, we cannot call it "COGEXEC", because we have cores. Right? REGEXEC may be. Or "Turbo nutter mode"?
That was pretty much the same thing I suggested three posts earlier. Just about any decent programmer will understand the "normal" mode (that we have been referring to as "hubexec"). And those same programmers will be floored when they discover that they can go beyond their "normal" mode in a way that no other microcontroller will allow: turbo (nutter) mode!
Anybody know when the new FPGA image will be available? Maybe it will stop this endless discussion about marketing nomenclature, and we can discuss more interesting technical details.
Anybody know when the new FPGA image will be available? Maybe it will stop this endless discussion about marketing nomenclature, and we can discuss more interesting technical details.
I doubt it. But an FPGA image would still be nice!
But why call it "native" it's just a processor executing code from RAM. Like all the others. They don't call it "native", why would they, that's just what they do.
Right it's just running code "on the metal" as I suggested before. You can call it "Pink Floyd" if you like. I don't care. It doesn't matter, but I called it native. It's not important.
Right it's just running code "on the metal" as I suggested before. You can call it "Pink Floyd" if you like. I don't care. It doesn't matter, but I called it native. It's not important.
The more I think about it, both COG mode and HUBEXEC mode are native. The non-native modes are CMM and XMM and, in the P1, LMM.
The idea of executing code from registers isn't new with the Propeller although it might be unique among microcontrollers. It was used in the DEC PDP-10 back in the '70's or maybe even earlier in the PDP-1. Not sure but it is a very old (but good!) idea.
Yep, there is nothing new under the sun. The Texas Instruments TMS9900 kept all it's registers (apart from program counter, stack pointer workspace register) in RAM. It could for sure execute code from it's own registers.
The more I think about it, both COG mode and HUBEXEC mode are native. The non-native modes are CMM and XMM and, in the P1, LMM.
The idea of executing code from registers isn't new with the Propeller although it might be unique among microcontrollers. It was used in the DEC PDP-10 back in the '70's or maybe even earlier in the PDP-1. Not sure but it is a very old (but good!) idea.
That's reasonable.
I'm going to call the native modes COG mode and HUB mode, and will continue to call the other modes CMM, LMM and XMM mode. The marketing people can use whatever terminology they like.
It's not important to you or me or any other Propeller fan. We know what it is already.
Pitching the device to a new guy is another matter, why confuse them with talking about "native" or "hubexec" ?
Of course! Pink Floyd is one of my favorite bands of all time. I was going to use that Russian female punk band name, but decided the Monkey might get me.
That's the point I was trying to make. I mentioned it before: "... just like all the other chips out there." it doesn't need a name. It just happens.
But, but, there is no LMM mode for the proposed Prop II.
We had this discussion a few pages back.
Catalina will continue to support LMM on the P1. On the P2 it will also support HUB mode. I may also leave LMM mode in on the P2, since I have to have it to support XMM mode anyway (which is effectively just LMM mode using a different type of memory).
That's the point I was trying to make. I mentioned it before: "... just like all the other chips out there." it doesn't need a name. It just happens.
Tosh. How are you going to categorize OBEX objects? "Now let me see ... this one uses COG mode only, so I can use it in my program, whereas that one uses ... err ... non-COG mode, so I can't".
How are you going to categorize OBEX objects? "Now let me see ... this one uses COG mode only, so I can use it in my program, whereas that one uses ... err ... non-COG mode, so I can't".
I might be missing a deep technical point here so please explain the problem.
Why does anything in OBEX need categorizing that way? Currently objects use HUB RAM (Generally Spin code), COG registers ( The PASM driver bits). Everything gets thrown into a project and just works.
The fact that a COG might be executing instructions from shared memory does not change anything.
Comments
As an outsider looking into to this endless debate about terminology and concepts, may I suggest you guys take an approach of looking at a broader picture versus looking deeper in the Propeller rabbit hole of it's own uniqueness. In fact, contrast and comparison is one of the core components of marketing (when there is in fact competition, some products may not have competition). The Propeller has competition. In the broader sense, you may argue that the Propeller does in fact "consolidate some fragmentation", for example, can a beginner program some of the more complex uC's? Is there off the shelf code for some of the more complex devices on the market for a beginner or advanced user? Is basis(Spin), ASM(pasm), C, and other unnamed variants available for other uC's so that multiple backgrounds can jump right in and start right away with limited hands on? Can other competitive products be hand soldered or as easily dropped in a design as quickly as a P1 (or the newer .5mm pitch coming soon)? Why does it matter if it is not called LMM if there is a term that is similar and alludes to it being usable in a like manner to LMM. All the minutia is great for internal discussion, but endless debate has not and is not producing a clear consider definition. For bigger successes, a broader, more mass appeal is needed. Nothing wrong with celebrating uniqueness when it does not impede growth and expansion, I have seen first hand many failures that were too unique. Why not PLMM, Prop LMM: similar to functionality of standard conventions of LMM, appeal to the masses, but retain some degree of uniqueness. I don't have intentions to use LMM or care what it is. What appealed to me in the beginning, and what continues to appeal to me, is the EASE of ADAPTING a SOLUTION to a PROBLEM. Which in a business sense means, taking my idea of a product, putting that idea into a working box, and selling it to someone else that finds value in it. In the end, the Propeller is solely for that purpose alone. Granted, the "working box" may be interchanged with an educational use or personal enjoyment use, but the concept still applies regarding adapting a solution to a problem, even if the problem is fun. The Propeller IS the problem solver for me. But, so many want to debate the nomenclature. If you view the problem through the lens of the "Propeller IS the solution", does that help refine the methods of explaining the Prop to the masses?
http://forums.parallax.com/showthread.php/155167-A-Propeller-by-any-other-name...
Chris Wardell
Perhaps these can become mapped registers. Good idea. The reason Prop2 uses to many GET/SET instructions is that it reduces what would have been mux'ing for both D and S, not to mention register space. Ah, one issue with having things like PTRx/INDx mapped is that they auto-increment and this would probably require some data-forwarding circuitry to ensure updated copies are used for the next D and S.
JMPSW is like JMPRET.
I can see how some kind of a compressed instruction set could be beneficial (as did the ARM folks with thumb mode), but that is a feature that the tool producer can call any TLA they like and some kind of an agreement on that is not required.
As far as cog or pasm code goes, the entry level tool can determine which compiler mode to use without burdening the simple user. Makefile users will need to understand when cog mode should be used or when pasm sections should be extracted, etc... and that is for the Makefile people to document and use, but that is not for simple users to care about.
Not "LMM" that's the technique invented by Bill Henning to allow running of Propeller instructions from RAM.
But this new PII can execute instructions from RAM anyway, without an LMM interpreter loop.
Surely that should be the default mode of operation.
The ability of the PII to execute instructions from it's own registers is weird and unique feature that can be used if you really need the performance and can live with the severe space limitation of 496 instructions.
We only need to compile "down to the metal" because an interpreter (as Chip called the Spin VM) is not required.
I agree with this attitude. This allows new people to start using it in a way they are already familiar with. When they realize what can actually be done with each of the cores, and that there is no other microcontroller out there that allows them to do the same thing, they will become as convinced of the power of the chip (and its paradigm) as we all are (regardless of whether they every actually use that capability). To that end, maybe we should refer to "hub mode" as the normal mode and "cog/core mode" as "turbo mode" (or similar phrase).
Also "exactly". "That is what I call "Native" (I don't really give a flying f*** what other people call it)."
But why call it "native" it's just a processor executing code from RAM. Like all the others. They don't call it "native", why would they, that's just what they do.
Executing code from your own resisters is weird and unique though, That is what should have a different name.
I think that we should stay with the terms that were used in P1, and it will reduce confusion when comparing P1+ to P1.
The terms COG, HUB and HUBEXEC have no meaning at all to the big world of micro-controller users. Explaining all that is a ten minute road block that we don't need. These terms also cause the Propeller to not show up in searches when people are looking for a solution to their problems.
Yes, the weird rotating cog diagram has to go. Every multi-core chip has to access RAM some how whilst fighting with its peers. That detail does not even show on product briefs.
The term HUBEXEC is just silly. Pretty much all multi-core machines execute code from such a shared memory.
"COGEXEC" is interesting. That is a unique Propeller feature as far as I know.
But hey, we cannot call it "COGEXEC", because we have cores. Right? REGEXEC may be. Or "Turbo nutter mode"?
Agreed
That sounds better, HUB needs to become simply Global/Shared RAM, pretty much like the 'big memory' on any controller.
REGister memory that can also EXECute is not something your average PIC16 user will have seen before.
That was pretty much the same thing I suggested three posts earlier. Just about any decent programmer will understand the "normal" mode (that we have been referring to as "hubexec"). And those same programmers will be floored when they discover that they can go beyond their "normal" mode in a way that no other microcontroller will allow: turbo (nutter) mode!
I doubt it.
An FPGA image might divert our attention a bit though, like throwing a bone to a pack of hungry wolves.
Right it's just running code "on the metal" as I suggested before. You can call it "Pink Floyd" if you like. I don't care. It doesn't matter, but I called it native. It's not important.
The idea of executing code from registers isn't new with the Propeller although it might be unique among microcontrollers. It was used in the DEC PDP-10 back in the '70's or maybe even earlier in the PDP-1. Not sure but it is a very old (but good!) idea.
Be careful with that axe Eugene.
It's not important to you or me or any other Propeller fan. We know what it is already.
Pitching the device to a new guy is another matter, why confuse them with talking about "native" or "hubexec" ?
Yep, there is nothing new under the sun. The Texas Instruments TMS9900 kept all it's registers (apart from program counter, stack pointer workspace register) in RAM. It could for sure execute code from it's own registers.
That's reasonable.
I'm going to call the native modes COG mode and HUB mode, and will continue to call the other modes CMM, LMM and XMM mode. The marketing people can use whatever terminology they like.
Ross.
But, but, there is no LMM mode for the proposed Prop II.
Well, not unless you want to make a super slow way of executing instructions with an unnecessary fetch execute kernel loop.
I'm very sure Catalina will not be supporting "dead snail mode"
No, Catalina will no doubt support "normal boring run code from RAM mode that no body gives a name to normally".
Of course! Pink Floyd is one of my favorite bands of all time. I was going to use that Russian female punk band name, but decided the Monkey might get me.
That's the point I was trying to make. I mentioned it before: "... just like all the other chips out there." it doesn't need a name. It just happens.
We had this discussion a few pages back.
Catalina will continue to support LMM on the P1. On the P2 it will also support HUB mode. I may also leave LMM mode in on the P2, since I have to have it to support XMM mode anyway (which is effectively just LMM mode using a different type of memory).
Ross.
Tosh. How are you going to categorize OBEX objects? "Now let me see ... this one uses COG mode only, so I can use it in my program, whereas that one uses ... err ... non-COG mode, so I can't".
How silly.
Ross.
I guess you mean "Pussy Riot".
If the moderator monkeys come for us we have to remind them they are acting like Vladimir Putin.
Why does anything in OBEX need categorizing that way? Currently objects use HUB RAM (Generally Spin code), COG registers ( The PASM driver bits). Everything gets thrown into a project and just works.
The fact that a COG might be executing instructions from shared memory does not change anything.
Ross, I don't understand what you mean. OBEX is comprised of Spin code. How is it relevant?
Just googled that and found someone talking about exactly that:
http://www.wiki.xilinx.com/ZYNQ-7000+AP+SoC+Lock+and+Execute+out+of+L2+Cache+Tech+Tip