All of my searches for information on the 'shadow registers' have not shown any result explaining the use of the shadow space as execution space. I wanted to fully explore the potabilities.(self modifying code executing from shadow registers...etc).
Those 16 long are just over 3% of the total COG memory so understanding how to fully use it could make a big difference.( at least to me).
Also I did know that the registers(CNT, INA, INB, PHYA, PHYB) were zeroed during initialization but why would the shadow registers need to be zeroed and not just filled with the data copied from the HUB during initialization?
LewisD,
I don't think any of us know whether the COG processor will fetch instructions from the "shadow registers" or from the actual registers. Chip and Beau are probably the only ones who know for sure and we'll have to wait for one of them to provide the information. Similarly, I don't believe anyone has said whether the "shadow registers" are cleared or loaded from the HUB memory during initialization. I suspect that they're loaded from the HUB since that would be simpler.
Mike
It is true, instruction execution was never discussed AFAIK and only answered by Chip some hours ago. Though it could easily have be checked by any one bold enough during all the time....
Note however that you can only use the 6 "read only" registers as mentioned above in that way, writing to the other 10 will have side effects....
You will find a driver or another where this space is used, with DJNZ instructions as variables... If you are after space, this is probably the better way to re-cycle them...
Zeroes: I THINK those zeroes are "written-through" to the attached hardware, thus re-assuring that the COG is in a defined state...
I believe Chip has indicated that all 16 COG RAM locations(Shadow Registers) can be used to execute code in.
I was also wondering if I could fill that space during a COGNEW...etc
I will give it a try when I get back to the lab later this week.
DeSilva,
I am familiar with using the DJNZ instructions to utilize some of the 'Shadow Register' space but I have not needed 16 nested DJNZ instructions, 3 or 4 maybe.( at least not yet)
Finding out that Executing code in that space is possible is just one more way to use the COG RAM to its fullest. It seem that no one else was aware of this capability.
It certainly should be listed in "Propeller Tricks and Traps". I will let Phil know.
It would also be useful to know if all 512 COG RAM location are indeed filled with HUB data during initialization. This would be the easiest way to get code/data into the 'Shadow Registers'.
Thanks for the help
LewisD
Chip said...
Cog RAM is read directly for instructions, not special 'source' registers such as PAR, CNT, etc. So, you could write a JMP instruction into the PAR register ($1F0) and have it execute, not having to consider what PAR would return as a 'source'. In other words, the large-model would work fine by reading eight contiguous hub longs into $1E8-$1EF and then JMPing to $1E8, and then having a JMP back execute from RAM (not PAR) at $1F0.
Chip how many of the registers are like that?(all?)
Yes, all. Some registers like PAR, CNT, INA, etc. have special mux's for reading live states when accessed as source registers. All instructions and destination registers are read from RAM, though - not mux's.
Its like the plague, soon as you think it's dormant it flares up again, and it's gotten so monsterous no one bothers to read the whole thing and just ends up asking the same questions over again.
Mike Green said...
LewisD,
I don't think any of us know whether the COG processor will fetch instructions from the "shadow registers" or from the actual registers. Chip and Beau are probably the only ones who know for sure and we'll have to wait for one of them to provide the information. Similarly, I don't believe anyone has said whether the "shadow registers" are cleared or loaded from the HUB memory during initialization. I suspect that they're loaded from the HUB since that would be simpler.
Mike
MIke, this has all been explained exactly in the way I did repeat in my posting. Sorry to hear you do not believe it :-(
I've asked Chip's permission to lock the thread, but it's just not something he wants to do. What I will do is start getting on top of keeping the thread as on topic as possible.
LewisD and deSilva, since discussion of the shadow registers in the current architecture is off topic, please take the discussion to its own thread.
My conversation with Chip was indeed on topic concerning what I would like to see in the Turboprop.
Chip let me know that what I wanted to do could also be done in the current Propeller.
Point taken though.
I will start a new tread if I need to explore this further.
I like this thread. It defines us as a community.
By the way, we should start a pool (awards by parallax, maybe) for when the propeller forum becomes the largest. And DON'T PUT YOUR GUESS HERE.
I am considering building VGA graphics terminal using Propeller chip. But current resolution is very too small for this purpose (as I found somewhere it is less than 550*400?).
Can someone from R&D team can tall what VGA resolution would TuprboProp (Prop2) will have? For my project 1024*768 is optimum required. Otherwise, I should consider use other technology.
And, since this is HUGE post (I don't have time to read all ;( ), could someone told me TurboProp estimate time?
Another option is to close the thread and open a new thread called part 2. That could start with some pertinent details to avoid repetition of "why can't we have more ram".
Ken Peterson said...
If the HUB doesn't execute anything, then what executes the loading of the cog RAM? Does the cog do that? Doesn't seem like it could, because it would be overwriting its own code.
I assume the bulk of COGINIT will execute on the target Cog. Where it performs the block copy then starts running the new program. Exactly how COGINIT takes control of the specified Cog I don't know.
This method has the advantage of inherently preventing the target Cog from running a mishmash of old and new code while the copy is in progress and also immediately takes the burden away from the issuing Cog.
Graham Stabler said...
Executing code and performing a hardwired task are not the same thing. The hub may contain circuitry to stick the boot program into cog ram but that doesn't mean it is running a program like a cog.
The hardwired COGINIT instruction is a normal instruction, just the first step of instruction fetching comes from the reset logic.
evanh said...
[noparse][[/noparse]I assume the bulk of COGINIT will execute on the target Cog. Where it performs the block copy then starts running the new program. Exactly how COGINIT takes control of the specified Cog I don't know.
Please respect Paul's request and post your speculations in another thread - I shall gladly answer to them and give more explanations
The harm is when others try to find information by thread title and we have a whole bunch of different topics in one huge thread that takes forever to sift through. The thread is so long it's practically useless for anyone trying to learn something. As several have commented, it can take a whole evening to read the entire thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
For what it's worth, the COGINIT instruction triggers the target cog to load ITSELF. The hub only enables/disables each cog's clock and reset, and serves hub memory read/write requests. It's the cog that loads itself and starts running. The hub just kicks off the process by resetting a cog and setting its load-start address.
I know it's probably kind of late in your development process, but has anyone suggested a specialist cog with much more internal ram than other cogs?
For those display-hungry and/or processing-rich applications, this big cog could handle bigger video maps than currently possible, among other things...
They run faster there too. Bit manupulation takes time --enough time that it makes perfect sense to just get the data from the HUB. This prop will actually do most practical resolutions just fine. It's got a color depth limitation, but that's really more about available RAM, not overall thoughtput and capability.
Right now, if you need serious color depth, check out the project Baggars put together. That's 24 bit color, and it's not all that complex. IMHO, it's highly likely to be far less complex than a good NTSC TV driver is.
If you want less, but still a better combination of resolution and color depth than the reference drivers demonstrate, there is the SRAM that Andre put together for HYDRA. The circuit is not complex, and there are video drivers in progress and running for it. So far, those have been TV drivers, utilizing the standard Propeller colors. (http://propeller.wikispaces.com/Colors) Those drivers, could very easily be doing VGA, or better. The result of that would be a solid bitmap at most practical resolutions. Draw speed might be somewhat limited. That's gonna depend on what you are thinking of doing. That is a speed / HUB memory access thing with the current Prop.
Then there is just getting nice intensity only displays. An 8bit DAC would yield about 160 color shades on your average TV / VGA monitor. Existing driver code, for timing, etc... can be leveraged, only changing the control signal palettes. The propeller builds the whole signal, so that consumes some of the bit-depth. Very cool though, because you get essentially any signal needed.
If a super-cog ends up in there, then symmetry is lost. Everybody is gonna code their objects to it, because it's the easiest one. Then, when one wants to mix and match, there is contention, rewrites, etc... required. It is more work, but more than one COG can generally be used to deal with the problem. Prop II will have 16 COGs, which will have a significant positive impact on this aspect of things.
One common need is for a somewhat large master program, leveraging smaller ones, running in the COGs. Right now, that really is SPIN. Soon, there will be a C compiler option, running large model assembly code. Performance will be somewhere between SPIN and native COG assembly. (Likely closer to assembly side of things.) This will, in essence, provide that master COG, for all but a very small number of use cases. From there, should you end up with one of those use cases, some thought will be required to apply more than one COG to the problem, or wait for the chip to scale again, or apply some hardware to the problem.
The super COG idea will limit the benefit said scaling will provide over the longer term. There are options, you've just gotta work for it!
Is it a possible to use internal MEMS resonator (SiTIME, Discera, etc.) with PLL in the new Propeller to refuse external quartz resonator?
In this case we receive fast, compact, stabile and very reliable chip for industrial and automotive applications.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Radio DELANET - modern electronics by own hands!
Radio DELANET said...
Is it a possible to use internal MEMS resonator (SiTIME, Discera, etc.) with PLL in the new Propeller to refuse external quartz resonator?
I doubt they are all that simple to integrate not to mention are they actually even on the same silicon yet? Guaranteed to add cost while the R-C oscillator doesn't.
I'd rather Parallax didn't hold up the production of the chip for that anyway. Bring on the Prop II! There will always be "coulda, woulda, shoulda" after it's launched anyway. One of the tough things about being an engineer is that you have to stop designing in order to start production.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
First of all let me say thanks to Chip.· You have sparked my imagination with the Propeller Chip.
I recently came across the Propeller chip and the first thing that came to mind was the TPU coprocessor or Time Processing unit from Motorola (now Freescale).· The thought process in the design was very similar and very different at the same time.· Both have a wack of timers a scheduler and a byte code interpreter (you have more than one).· If I could·think of one·thing the Propeller could use in my opinion is a second time base.· There is only one shared time base between the Cogs which is the System Counter.· For many applications that I work on I need a second time base. ·I actually use the other time base as an angular counter and not a time base at all.· For example in an internal combustion engine you need to keep track of the angular position of the crankshaft and trigger events based upon this angle.· Some of the events are angle triggered and time limited.· Other events are angle triggered and also ended on an angle.··I don't think this would be very hard to introduce into the current design·and would not require years of development work like the modifications currently suggested.· Anyways think of the possiblities of tracking a clock and an encoder simultaneously and triggering events·on either and angle in the future or a time in the future.
waitcnt(time) or waitang(angle)
I think you get my idea.· I am eagerly awaiting my development kit to see what kind of timing I can get by using a COG monitoring an encoder that updates the position in main memory.· Based on what I have read I should be able to get uS resolution running at 80Mhz.
@The Outfield: Being a "good boy" I shall not answer to this posting in this thread as it is OT. But If you would post is otherwhere, we can show you how to use the many timers in the Prop to do what you most likely are looking for.
TheOutfield said...
... think of the possiblities of tracking a clock and an encoder simultaneously and triggering events on either and angle in the future or a time in the future.
While the quadrature decoding has to be done in software, and I have (expletive)ed about this with other micros, a Cog is more than fast enough for this job and the rest of the processing has to be done in software anyway so I think you'll find the Propeller will suit your application. There is example Quadrature Encoder object. (Are those objects editable?)
Short answer is that no extra devices will be added to the Prop2. The Counters/PLL circuit in each Cog is pretty much it. The main topic in this thread is execution speed and memory space.
Comments
All of my searches for information on the 'shadow registers' have not shown any result explaining the use of the shadow space as execution space. I wanted to fully explore the potabilities.(self modifying code executing from shadow registers...etc).
Those 16 long are just over 3% of the total COG memory so understanding how to fully use it could make a big difference.( at least to me).
Also I did know that the registers(CNT, INA, INB, PHYA, PHYB) were zeroed during initialization but why would the shadow registers need to be zeroed and not just filled with the data copied from the HUB during initialization?
LewisD
I don't think any of us know whether the COG processor will fetch instructions from the "shadow registers" or from the actual registers. Chip and Beau are probably the only ones who know for sure and we'll have to wait for one of them to provide the information. Similarly, I don't believe anyone has said whether the "shadow registers" are cleared or loaded from the HUB memory during initialization. I suspect that they're loaded from the HUB since that would be simpler.
Mike
Note however that you can only use the 6 "read only" registers as mentioned above in that way, writing to the other 10 will have side effects....
You will find a driver or another where this space is used, with DJNZ instructions as variables... If you are after space, this is probably the better way to re-cycle them...
Zeroes: I THINK those zeroes are "written-through" to the attached hardware, thus re-assuring that the COG is in a defined state...
I believe Chip has indicated that all 16 COG RAM locations(Shadow Registers) can be used to execute code in.
I was also wondering if I could fill that space during a COGNEW...etc
I will give it a try when I get back to the lab later this week.
DeSilva,
I am familiar with using the DJNZ instructions to utilize some of the 'Shadow Register' space but I have not needed 16 nested DJNZ instructions, 3 or 4 maybe.( at least not yet)
Finding out that Executing code in that space is possible is just one more way to use the COG RAM to its fullest. It seem that no one else was aware of this capability.
It certainly should be listed in "Propeller Tricks and Traps". I will let Phil know.
It would also be useful to know if all 512 COG RAM location are indeed filled with HUB data during initialization. This would be the easiest way to get code/data into the 'Shadow Registers'.
Thanks for the help
LewisD
Post Edited (LewisD) : 10/9/2007 9:37:44 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
BTW. I have read the whole thing it took me all evening but·I read it all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My computer, http://forums.parallax.com/showthread.php?p=630466
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
MIke, this has all been explained exactly in the way I did repeat in my posting. Sorry to hear you do not believe it :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
LewisD and deSilva, since discussion of the shadow registers in the current architecture is off topic, please take the discussion to its own thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
My conversation with Chip was indeed on topic concerning what I would like to see in the Turboprop.
Chip let me know that what I wanted to do could also be done in the current Propeller.
Point taken though.
I will start a new tread if I need to explore this further.
Thanks
LewisD
By the way, we should start a pool (awards by parallax, maybe) for when the propeller forum becomes the largest. And DON'T PUT YOUR GUESS HERE.
I am considering building VGA graphics terminal using Propeller chip. But current resolution is very too small for this purpose (as I found somewhere it is less than 550*400?).
Can someone from R&D team can tall what VGA resolution would TuprboProp (Prop2) will have? For my project 1024*768 is optimum required. Otherwise, I should consider use other technology.
And, since this is HUGE post (I don't have time to read all ;( ), could someone told me TurboProp estimate time?
Tnx!
Another option is to close the thread and open a new thread called part 2. That could start with some pertinent details to avoid repetition of "why can't we have more ram".
Graham
This method has the advantage of inherently preventing the target Cog from running a mishmash of old and new code while the copy is in progress and also immediately takes the burden away from the issuing Cog.
The hardwired COGINIT instruction is a normal instruction, just the first step of instruction fetching comes from the reset logic.
Evan
Besides, I don't see the harm really.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
For those display-hungry and/or processing-rich applications, this big cog could handle bigger video maps than currently possible, among other things...
Besides, the memory maps used for video generation are stored in HUB RAM, not in the COG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Right now, if you need serious color depth, check out the project Baggars put together. That's 24 bit color, and it's not all that complex. IMHO, it's highly likely to be far less complex than a good NTSC TV driver is.
If you want less, but still a better combination of resolution and color depth than the reference drivers demonstrate, there is the SRAM that Andre put together for HYDRA. The circuit is not complex, and there are video drivers in progress and running for it. So far, those have been TV drivers, utilizing the standard Propeller colors. (http://propeller.wikispaces.com/Colors) Those drivers, could very easily be doing VGA, or better. The result of that would be a solid bitmap at most practical resolutions. Draw speed might be somewhat limited. That's gonna depend on what you are thinking of doing. That is a speed / HUB memory access thing with the current Prop.
Then there is just getting nice intensity only displays. An 8bit DAC would yield about 160 color shades on your average TV / VGA monitor. Existing driver code, for timing, etc... can be leveraged, only changing the control signal palettes. The propeller builds the whole signal, so that consumes some of the bit-depth. Very cool though, because you get essentially any signal needed.
If a super-cog ends up in there, then symmetry is lost. Everybody is gonna code their objects to it, because it's the easiest one. Then, when one wants to mix and match, there is contention, rewrites, etc... required. It is more work, but more than one COG can generally be used to deal with the problem. Prop II will have 16 COGs, which will have a significant positive impact on this aspect of things.
One common need is for a somewhat large master program, leveraging smaller ones, running in the COGs. Right now, that really is SPIN. Soon, there will be a C compiler option, running large model assembly code. Performance will be somewhere between SPIN and native COG assembly. (Likely closer to assembly side of things.) This will, in essence, provide that master COG, for all but a very small number of use cases. From there, should you end up with one of those use cases, some thought will be required to apply more than one COG to the problem, or wait for the chip to scale again, or apply some hardware to the problem.
The super COG idea will limit the benefit said scaling will provide over the longer term. There are options, you've just gotta work for it!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Is it a possible to use internal MEMS resonator (SiTIME, Discera, etc.) with PLL in the new Propeller to refuse external quartz resonator?
In this case we receive fast, compact, stabile and very reliable chip for industrial and automotive applications.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Radio DELANET - modern electronics by own hands!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
I recently came across the Propeller chip and the first thing that came to mind was the TPU coprocessor or Time Processing unit from Motorola (now Freescale).· The thought process in the design was very similar and very different at the same time.· Both have a wack of timers a scheduler and a byte code interpreter (you have more than one).· If I could·think of one·thing the Propeller could use in my opinion is a second time base.· There is only one shared time base between the Cogs which is the System Counter.· For many applications that I work on I need a second time base. ·I actually use the other time base as an angular counter and not a time base at all.· For example in an internal combustion engine you need to keep track of the angular position of the crankshaft and trigger events based upon this angle.· Some of the events are angle triggered and time limited.· Other events are angle triggered and also ended on an angle.··I don't think this would be very hard to introduce into the current design·and would not require years of development work like the modifications currently suggested.· Anyways think of the possiblities of tracking a clock and an encoder simultaneously and triggering events·on either and angle in the future or a time in the future.
waitcnt(time) or waitang(angle)
I think you get my idea.· I am eagerly awaiting my development kit to see what kind of timing I can get by using a COG monitoring an encoder that updates the position in main memory.· Based on what I have read I should be able to get uS resolution running at 80Mhz.
Short answer is that no extra devices will be added to the Prop2. The Counters/PLL circuit in each Cog is pretty much it. The main topic in this thread is execution speed and memory space.