This only changes the compiler, which now must recognize #LO, #HI, #XOR, #OFF, #Z, #NZ, #C, #NC as reserved names, but simplifies it down to one instruction.
This reduces the instruction count (theoretically) and simplifies the manual.
The only change to the existing instruction coding is I have rearranged the lower 3 bits of "S" (mainly to permit #0 and #1 for CLR and SET).
Thoughts anyone???
Does GETP become GETPIN and GETNP become GETNPIN so it's consistent?
This only changes the compiler, which now must recognize #LO, #HI, #XOR, #OFF, #Z, #NZ, #C, #NC as reserved names, but simplifies it down to one instruction.
Did you mean one assembler mnemonic, rather than one instruction.
There are still 8 unique opcodes/instructions.
A single form has merit, but if you want to use a param to indicate the action then SETPIN is better as MOVPIN, or WRPIN
SETP was already use to SET the pin - most programmers expect SET to do what it says
MOVPIN/WRPIN semantics work on all cases, except for the XOR case, where #XOR is a little confusing.
To keep a common name of WRPIN & using your form, then this would do what it says.
Haven't we been calling the mode where code resides in external memory XMM mode? I don't think we need a new term for this new chip.
Fair point. XMM is really just LMM with a different storage medium. But we could have CMM, LMM, XMM and this new Hubexec mode. I'm not yet sure whether this new Hubexec mode will completely replace hub-based LMM or not.
Fair point. XMM is really just LMM with a different storage medium. But we could have CMM, LMM, XMM and this new Hubexec mode. I'm not yet sure whether this new Hubexec mode will completely replace hub-based LMM or not.
Ross.
How would hub-based LMM be useful if we have the ability to execute code directly from the hub?
Technically LMM is not the right word. The point is that LMM used 32 bit instructions, and there will be little difference in size of code in for the same programs between LMM and hubexec/native/default whatever it's called. CMM will probably still be a valid thing to have. Given the amount of head-room we may end up with more interesting things too. Mixed code models though? Isn't that a bit bizarre? Seems rather complicated - maybe worth a white paper.
So, there is:
RMM -Register Memory Model, where the code goes into those new executable registers. Some might call it COG
CMM - where you have the compact code VM running and some really big programs in 512KB
(Native) - where you are running in a big flat memory model like everyone else (512KB of native code!!!)
XMM - where you're running out of extended memory.....and your 512KB is used for what? Really big cache space?
How would hub-based LMM be useful if we have the ability to execute code directly from the hub?
It may not be - but we won't know until Hubexec becomes a reality. But you certainly can't call it LMM - that would be very confusing for a compiler (like Catalina) that intends to support both the P1 and this new chip.
It may not be - but we won't know until Hubexec becomes a reality. But you certainly can't call it LMM - that would be very confusing for a compiler (like Catalina) that intends to support both the P1 and this new chip.
Ross.
That is why I think we should stick with XMM. Executing code directly from hub memory will become the default mode I think just like LMM was before.
That is why I think we should stick with XMM. Executing code directly from hub memory will become the default mode I think just like LMM was before.
Yes, but even if we don't have LMM on this chip, we'll still have CMM, LMM, XMM on the P1, and then CMM, "this new mode" and XMM on the P2.
So I'd prefer if "this new mode" was not referred to as LMM, because at present it looks like all the other modes can be kept compatible at the assembly level between the two chips (as long as Parallax does not make too many changes to the existing instruction set) - but LMM would be very different.
If you don't like HMM, we could just stick with calling it HUBEXEC. Or just HUB.
Yes, but even if we don't have LMM on this chip, we'll still have CMM, LMM, XMM on the P1, and then CMM, "this new mode" and XMM on the P2.
So I'd prefer if "this new mode" was not referred to as LMM, because at present it looks like all the other modes can be kept compatible at the assembly level between the two chips (as long as Parallax does not make too many changes to the existing instruction set) - but LMM would be very different.
If you don't like HMM, we could just stick with calling it HUBEXEC. Or just HUB.
Ross.
How about RAM to keep with the new common terms marketing direction? HUB is out RAM is in.
Since we're all starting to make requests on the specs of this new chip, can I ask for the SERIN/SEROUT instructions? Are they big power hogs or large blocks of silicon?? Maybe just SERA and not SERB?
I haven't seen the reply for this one. Will SERIN/SEROUT be removed from this chip?
I haven't seen the reply for this one. Will SERIN/SEROUT be removed from this chip?
Last I heard, Chip was thinking of support for some serial functions on the new Pin Counter cell.
Data Bandwidth values are still somewhat undefined...
Chip,
May I suggest that the PC counter and immediate values be 18 bits long instead of 17 bits long.
This way, should subsequent chips have 1MB of hub ram, we don't have to change anything???
There is room in the instruction set to have the opcodes 11101xx use one of those bits instead of D[8].
The saving of Z,C,PC to $1EF would be 0000000_00_0_00ZC_<18bitPC>
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?
We should kill these terms "HUB" and "COG" and "hubexec".
The RAM on the PII is the "RAM". Just like any other micro-controller.
A COG is a "processor".
Yes there is a HUB mechanism arbitrating memory access between processors but that is a little implementation detail.
"hubexec" is just "normal execution", why give it a weird meaningless name?
Executing instructions from it's own CPU registers is the weird thing. That's something a Propeller II does that is really unfamiliar to most people.
"LMM" is right out.
propgcc and other compilers should not carry this old confusing terminology forward to the PII.
We should kill these terms "HUB" and "COG" and "hubexec".
The RAM on the PII is the "RAM". Just like any other micro-controller.
A COG is a "processor".
Yes there is a HUB mechanism arbitrating memory access between processors but that is a little implementation detail.
"hubexec" is just "normal execution", why give it a weird meaningless name?
Executing instructions from it's own CPU registers is the weird thing. That's something a Propeller II does that is really unfamiliar to most people.
"LMM" is right out.
propgcc and other compilers should not carry this old confusing terminology forward to the PII.
Utter rubbish. Use whatever marketing terminology you like to get the punters to pay attention, but if you continue to try and pretend that cogs are nothing more than cores, and Hub RAM is nothing more than RAM, you will probably not be surprised when the punters decide to completely ignore the Propeller because the latest ARM processor has more cores, more RAM, more Mhz and is cheaper.
...but if you continue to try and pretend that cogs are nothing more than cores, and Hub RAM is nothing more than RAM,
I think I read that from you before. Didn't understand it then. Don't understand it now.
In what way, is a COG any more than a "core" or "processor"?
Yes, it carries with it counters and video things but that doesn't change it in my mind. From a programming perspective it is what has become commonly known as a "core" now a days. With some local extras.
In what way is HUB RAM not just RAM?
Don't despair, please explain what I'm missing here.
I still think HUB RAM should be "shared" or something RAM, just because of the multi-core environment.
Like the idea of calling cog RAM "registers", all 512 of them.
Don't know what to call the way we used to do things... "execute from register space" maybe? "local execution"?
For me, the Propeller lies in the space in between cheap, simple microcontrollers and overly complex ARM/FPGA.
The other great thing about Propeller was all the free tools and free example code, etc.
I think this new chip will still be in this area.
We compare apples to pears and don't call them fruit. Look to here: https://en.wikipedia.org/wiki/Flynn%27s_taxonomy. The propeller is unique and will be unique for the next time. If you see the propeller as a SPIN-machine, then you have one global, shared memory and 8 cores, running in parallel. But if your point of view changes to see the COGS, you have eight register machine, normally called RISC machines, which have access to a common external memory. But as they share also the I/O, the can communicate via I/O-pins. And this will extend, as the new versions come to the light.
By the way: I found, there are two types of software engineers: those who hate to not use the resources of a given hardware and those who love to use resources that do not exist yet.
I think I read that from you before. Didn't understand it then. Don't understand it now.
In what way, is a COG any more than a "core" or "processor"?
Yes, it carries with it counters and video things but that doesn't change it in my mind. From a programming perspective it is what has become commonly known as a "core" now a days. With some local extras.
In what way is HUB RAM not just RAM?
Don't despair, please explain what I'm missing here.
I'm afraid if you don't get it by now, there is simply no hope - not for you, and (probably) not for the Propeller. What hope do we have if even some of the supposed cognoscenti don't get it? Multi-core processors are a dime a dozen. The Propeller is unique (as far as I know) in the micro-controller domain.
Yes, but even if we don't have LMM on this chip, we'll still have CMM, LMM, XMM on the P1, and then CMM, "this new mode" and XMM on the P2.
So I'd prefer if "this new mode" was not referred to as LMM, because at present it looks like all the other modes can be kept compatible at the assembly level between the two chips (as long as Parallax does not make too many changes to the existing instruction set) - but LMM would be very different.
If you don't like HMM, we could just stick with calling it HUBEXEC. Or just HUB.
Ross.
I agree that executing native code from hub memory should not be called LMM. I like just calling it "native mode" but if it must fit into the TLA naming convention how about NMM?
I agree that executing native code from hub memory should not be called LMM. I like just calling it "native mode" but if it must fit into the TLA naming convention how about NMM?
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.
Comments
Does GETP become GETPIN and GETNP become GETNPIN so it's consistent?
Did you mean one assembler mnemonic, rather than one instruction.
There are still 8 unique opcodes/instructions.
A single form has merit, but if you want to use a param to indicate the action then SETPIN is better as MOVPIN, or WRPIN
SETP was already use to SET the pin - most programmers expect SET to do what it says
MOVPIN/WRPIN semantics work on all cases, except for the XOR case, where #XOR is a little confusing.
To keep a common name of WRPIN & using your form, then this would do what it says.
WRPIN #NOTPIN
and pairs with
RDPIN
Fair point. XMM is really just LMM with a different storage medium. But we could have CMM, LMM, XMM and this new Hubexec mode. I'm not yet sure whether this new Hubexec mode will completely replace hub-based LMM or not.
Ross.
RMM -Register Memory Model, where the code goes into those new executable registers. Some might call it COG
CMM - where you have the compact code VM running and some really big programs in 512KB
(Native) - where you are running in a big flat memory model like everyone else (512KB of native code!!!)
XMM - where you're running out of extended memory.....and your 512KB is used for what? Really big cache space?
It may not be - but we won't know until Hubexec becomes a reality. But you certainly can't call it LMM - that would be very confusing for a compiler (like Catalina) that intends to support both the P1 and this new chip.
Ross.
Perhaps extending that further to include the Smart-IO stuff, an "alias" of the message command for the Smart-IO?
e.g.
SETPIN #pin,#AI '(Analog In)
SETPIN #pin,#AO,#value '(Analog Out)
SETPIN #pin,#PWM,#value
etc,etc...
http://forums.parallax.com/showthread.php/155195-New-16-Cog-512KB-Instruction-Semantics-discussion?p=1259088#post1259088
Yes, but even if we don't have LMM on this chip, we'll still have CMM, LMM, XMM on the P1, and then CMM, "this new mode" and XMM on the P2.
So I'd prefer if "this new mode" was not referred to as LMM, because at present it looks like all the other modes can be kept compatible at the assembly level between the two chips (as long as Parallax does not make too many changes to the existing instruction set) - but LMM would be very different.
If you don't like HMM, we could just stick with calling it HUBEXEC. Or just HUB.
Ross.
How about RAM to keep with the new common terms marketing direction? HUB is out RAM is in.
I like Native ;-)
I could live with that.
Ross.
I haven't seen the reply for this one. Will SERIN/SEROUT be removed from this chip?
No way - it's not a TLA!
Last I heard, Chip was thinking of support for some serial functions on the new Pin Counter cell.
Data Bandwidth values are still somewhat undefined...
LOL
It sure is!
RAM Addressability Model -RAM
Geez! Do I have to explain everything??
May I suggest that the PC counter and immediate values be 18 bits long instead of 17 bits long.
This way, should subsequent chips have 1MB of hub ram, we don't have to change anything???
There is room in the instruction set to have the opcodes 11101xx use one of those bits instead of D[8].
The saving of Z,C,PC to $1EF would be 0000000_00_0_00ZC_<18bitPC>
Just thought it needed to be mentioned again as we seem to be creeping again...
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?
The RAM on the PII is the "RAM". Just like any other micro-controller.
A COG is a "processor".
Yes there is a HUB mechanism arbitrating memory access between processors but that is a little implementation detail.
"hubexec" is just "normal execution", why give it a weird meaningless name?
Executing instructions from it's own CPU registers is the weird thing. That's something a Propeller II does that is really unfamiliar to most people.
"LMM" is right out.
propgcc and other compilers should not carry this old confusing terminology forward to the PII.
Utter rubbish. Use whatever marketing terminology you like to get the punters to pay attention, but if you continue to try and pretend that cogs are nothing more than cores, and Hub RAM is nothing more than RAM, you will probably not be surprised when the punters decide to completely ignore the Propeller because the latest ARM processor has more cores, more RAM, more Mhz and is cheaper.
I despair of this forum sometimes.
Ross.
In what way, is a COG any more than a "core" or "processor"?
Yes, it carries with it counters and video things but that doesn't change it in my mind. From a programming perspective it is what has become commonly known as a "core" now a days. With some local extras.
In what way is HUB RAM not just RAM?
Don't despair, please explain what I'm missing here.
Like the idea of calling cog RAM "registers", all 512 of them.
Don't know what to call the way we used to do things... "execute from register space" maybe? "local execution"?
For me, the Propeller lies in the space in between cheap, simple microcontrollers and overly complex ARM/FPGA.
The other great thing about Propeller was all the free tools and free example code, etc.
I think this new chip will still be in this area.
By the way: I found, there are two types of software engineers: those who hate to not use the resources of a given hardware and those who love to use resources that do not exist yet.
I'm afraid if you don't get it by now, there is simply no hope - not for you, and (probably) not for the Propeller. What hope do we have if even some of the supposed cognoscenti don't get it? Multi-core processors are a dime a dozen. The Propeller is unique (as far as I know) in the micro-controller domain.
From the wikipedia entry on multi-core processors:
Even this very first sentence is not true of the Propeller, and the rest of the description becomes less and less relevant.
Ross.
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.