Think I'm crazy? Well perhaps but perhaps also we should generally change the perspective that COG RAM is instruction/memory space.
Lets say it's NOT.
Instead, what we have here is eight 32bit CPUs with 496 REGISTERS each. I mean, WOW amazing !!!
Now, COGs of course are a bit weird in that you have to load an instruction into a register before it can be executed. By default that happens with COGNEW loading everything but it can also be done by some LMM mechanism as in the ImageCraft C compiler etc. Or by some overlay mechanism.
My observation is that many real-time embedded systems have high speed/priority parts which are actually very small and normally allocated to interrupt handlers. The bulk of the code being contained in a background loop that idles around as best it can.
So, given that the high speed/priority parts are small, we see that the need to put large junks of code actually into a COG should be the exception rather than the rule. The bulk of it should be running at a slower pace via LMM or even SPIN as we have now.
The perspective I'm proposing is that we have 1 general purpose CPU (GOG) running 90% of the code and then we have 7 processors handling what would otherwise be interrupts on a traditional system but with the important bonus of timing determinism of dedicated CPUs. Or partition it as 2 to 6 or whatever as appropriate.
Whilst we are at it, this "new" perspective should finally put out of peoples minds the recurring request that COGs have interrupt handling capability. With this view we see that COGs ARE interrupt handlers. But far better, they have timing determinism and we don't have to mess around with interrupt controllers and priority schemes or stacks. All our 7 (or whatever) interrupts are already at the highest priority and none of them need a stack!.
Currently the way COGNEW works and the way SPIN objects are seems to encourage the idea that COGs are general purpose CPUs that we load up with objects but damn they are so small.
I think the view I'm outlining here will become even more relevant with the much higher speed of the PROP II and assistance of it's improved serial I/O to remove the burden of bit banging from actual code.
This view highlights the need for PROP II to enable running LMM code as fast as possible.
Hope I have managed to express this coherently, I'm in a bit of a hurry here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I can´t express it so fine but
Both LMM and say "overlays" I define its "Cogcodeobjects" have its benefits.
LMM for large programs. "Cogcodeobjects" for fast code run if code = INIT+RUN>COG REGS/RAM.
And if "Cogcodeobjects" can solve it INIT reload RUN
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
I think you've got a good grip on how it's all going to play out.
I see the thing as registers too! It's a lot like just having instructions execute in the registers for the highest speeds. When running LMM, it acts more like a *regular* CPU.
The LMM enhancements being discussed here are going to put the COG memory space problem to rest big time. And the C / LMM PASM programmers are gonna see plenty of performance, meaning you can kind of ignore the COG thing altogether, if you want to.
Another way I see this is that each COG is either a CPU, in the traditional sense, running SPIN or LMM, or it's emulating some hardware (graphics, sound, external memory banking, I/O, etc...). Instead of globbing on a lot of dedicated hardware, you just spend some time in software connecting things together.
I like the focus of tuning the instruction set for LMM / multi-thread. This discussion is going to put most of the current Prop exceptions off the table. Way to go guys!
Yep, I also realised they were already on to that line of thinking straight after I'd posted the idea myself. It's funny how, when one is only picking up little bits of the conversation, that you can latch onto the gist of it and not even realise it. O_o
I believe they are trying to iron out a task switcher rather than processor threading. Whether it's targetted at just LMM, or both native and LMM, I'm not too sure.
heater said... COG RAM is NOT instruction/memory space.
Think I'm crazy? Well perhaps but perhaps also we should generally change the perspective that COG RAM is instruction/memory space.
Lets say it's NOT.
Instead, what we have here is eight 32bit CPUs with 496 REGISTERS each. I mean, WOW amazing !!!
···· Youre only going to confuse noobs by saying this.· As the von neumann architecture postulates that·the processor registers ARE read-write RAM.· Look at the picture of the die again, the COG ram obviously uses a separate threshhold of blocks on the die·as the COG logic does.·
Chip Gracey said...
And none of these are HUBOPs, they're all %000110 instructions (was slated for ENC), so they are single-cycle.
Got it! I assume that, as in the HUBOPs, S is being used as an opcode extension, which rules out its use as an operand, right? (Those bits have gotta go somewhere! )
-Phil
That's right. When you see constants being expressed within brackets for new instructions, those bits are going into the S (mainly) and D (occasionally) fields.
A question about TASKxxx. When the cog starts, would the foreground program automatically be task 0? Or would the first TASKNEW transfer control to the task manager, not to return until the task queue is empty again? If the foreground program is task 0, will there be a mechanism to force a COGSTOP when the task queue becomes empty? Or would task 0 simply not be allowed to END itself?
-Phil
Yes, when the cog starts, only task 0 would be active. As soon as other tasks·would be·enabled, they would start taking time slots. As they shut down, those slots woudl be freed. There is no need for a TASKNXT instruction, as the granularity of a task is·a single-instruction. So, TASKNXT (pass to next task) would be the same as a NOP. And, since you mentioned it (it hadn't occured to me), it is clear that if there were no more tasks, a COGSTOP would have to be done automatically. Otherwise, the cog would become a zombie.
Chip Gracey (Parallax) said...
... as the granularity of a task is a single-instruction.
!!! How deterministic? Are we talking two tasks guaranteed half clock rate each?
Is this native Cog code? Isn't the binary register references absolute in native code?
Bit of a squeeze in the Cogs already I thought.
I don't know if this has been explored fully, but theres the issue of how to handle hub accesses in a task switcher. When there is a mulitple of 2 tasks running, a single process will always "own" the hub access by nature of it's alignment with the hub access window. Things such as a 2 bit, depth of 4, fifo for prioritizing hub accesses between the tasks can be implemented, but it's something that must be planned for. Unless the determination is made that only one process can be used for hub accesses and it serves the function of data transfer process for the other processes.
Night of the living zombie cogs, I see a badly made geek horror movie here [noparse]:)[/noparse]
Can somebody point me to any LMM docs out there? Everybody talks about LMM but there doesn't seem to be any real documentation provided by anyone or at least divulged publicly.
And are there any code examples of the LMM programming language that some here are talking about?
Chip Gracey said...
There is no need for a TASKNXT instruction, as the granularity of a task is a single-instruction. So, TASKNXT (pass to next task) would be the same as a NOP.
Chip,
Please forgive my confusion, but I thought that instruction-level task switching was off the table due to pipeline complications and that the TASKxxx instructions were for cooperative multitasking, wherein each task gets to decide when to hand off control. Hence my TASKNXT comment. If the instruction-level interleaving is still doable, that's fantastic! I was ready to be satisfied with less.
Yeah I'm getting a little lost myself on what has and hasn't been discounted. One possible run around with the stalling pipeline is to have 4 seperate pipelines, one for each task (thered also need to be seperate z and c flags and PC registers) with 1:4 muxs everywhere. Then when one task stalls on rdxxxx/wrxxxx or waitxxx, the other pipelines crunch along happily completely oblivious to thier stalled bother. But the amount of silicon required for all this stuff may end up being prohibitive (how many "ways" would the ram need to be, or could the existing 4-way be muxed as well?) One thing thats interesting is if you have 1 task running and 3 "nop" tasks, you can achieve backwards compatibility with the current 1 instruction/4 clock cycles. Don't know how useful that would be but it's interesting.
Inasmuch as the Propellor I is still so relatively new, I don't think many of us have even really become what could be considered thoroughly competent with it. Consequently, a compatibility and learning curve issue doesn't, in my opinion exist. Go with the flat memory map and make it easier on yourself. After all, it's YOUR baby!
I'm back after many months: getting engaged, going on a cruise, getting married, moving to a house, putting condo on market, setting up in new home...
And what do I see? TONS of progress!
More below:
Paul Baker (Parallax) said...
Yeah I'm getting a little lost myself on what has and hasn't been discounted. One possible run around with the stalling pipeline is to have 4 seperate pipelines, one for each task (thered also need to be seperate z and c flags and PC registers) with 1:4 muxs everywhere. Then when one task stalls on rdxxxx/wrxxxx or waitxxx, the other pipelines crunch along happily completely oblivious to thier stalled bother. But the amount of silicon required for all this stuff may end up being prohibitive (how many "ways" would the ram need to be, or could the existing 4-way be muxed as well?) One thing thats interesting is if you have 1 task running and 3 "nop" tasks, you can achieve backwards compatibility with the current 1 instruction/4 clock cycles. Don't know how useful that would be but it's interesting.
Paul, I've skimmed over this massive thread, and I love what I am seeing Chip et al propose for Prop II. Here are some initial ideas and feedback, more over the next few days as I digest what has been going on in the forum in my absence.
1) RE: 8 cogs / 256K due to die increase and wanting to have a HUB cycle every eight accesses
That works, however I seem to recall a proposal sometime in the past for a 12 cog design - which would have eight cogs with 1:16 hub cycles and four at 1:8
This solves both problems - four cogs get HUB access every 8 cycles, assuming a 160MHz clock, 20M hub cycles per second per clock, reading/writing longs that's 80MB/sec per fast cogs; the eight "slow" cogs get 40MB/sec.... so the fast ones get 4x the current memory bandwidth, the slow ones get 2x
I saw chips "cache line read" idea, while elegant for video renderer, it would complicate LMM's; instead why not add RDDOUBLE/WRDOUBLE - only relatively minor expansion in multiplexers for the hub memory, yet doubles the memory bandwidth shown above; also would be compatible with future 64 bit props [noparse]:)[/noparse]
2) RE: HARDWARE THREADS
I LOVE IT! I think Paul's idea is excellent, let's say only thread 0 has HUB memory access; allows timing to be deterministic for all threads. I'd be tempted to assign WAITVID to a different thread... I will chew on this more. I really, really like this - one cog could easily handle serial + kb + mouse!
3) RE: new addressing modes
offsets & auto inc/dec for hub... EXCELLENT!
indirection cog ram... WAY TO GO!
Way to go Chip, exactly what we need.
4) RE: portA / portB multiplexer
Good idea, frees up a few registers, maybe make the indirection pointers visible instead?
Could we also have a virtual port C? (or V) whose 32 bits we could use for inter-cog faster than hub sync?
5) Ideas I'd like to suggest for discussion:
a) since the port indexing is available, how about using one of the freed up registers to hold the PC and the flags for the current cog?
that would free up some instructions as it would be possible to move new addresses directly into the PC, branch by adding/subbing from it etc
there could be "shadows" of it, one for each thread
b) since there is cog indirect addressing... how about adding another 512 longs of cog memory, to be used as scan line buffers, high speed
sampling buffers, cog based stack et al? I can see soooooo many uses for this its not even funny!
c) an LMM instruction, that uses the auto-incremented pointer to fetch/exec the instruction [noparse]:)[/noparse] saves cog code space
d) I'd love more detail on the new in/out shift registers, I'd really like 10/100mbps ethernet, and at least 12mbps USB without external HW
e) I'd still love a fast single-instruction "replace any byte/word in a register with any byte/word from another"
f) "input mask register" for each port; anded with actual input, would allow for zeroing un-interesting bits in inputs
6) RADICAL IDEA
Who says a byte has to be eight bits?
If PropII was a 36 bit processor, we'd have four new bits per word... two for each address field [noparse]:)[/noparse]
would allow for:
- 2K longs per cog!
- easy 512 color VGA
- more instructions by exposing PC and flags gets rid of some JUMP opcodes
Ok, more later, after I do a LOT of reading to start to catch up. Great to see the C compiler, must play with it.
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
If PropII was a 36 bit processor, we'd have four new bits per word... two for each address field [noparse]:)[/noparse]
would allow for:
- 2K longs per cog!
- easy 512 color VGA
- more instructions by exposing PC and flags gets rid of some JUMP opcodes
Excellent idea, but what about main ram? How can a COG be loaded (COGINIT) from main ram if main ram is still 32 bits per word?
Mark
Thanks [noparse]:)[/noparse] Obviously HUB ram would have to go 36 bit... ditto for the rom... I can't be the only one who remembers old machines with 18 / 36 bit words...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 8/30/2008 11:18:47 PM GMT
Bill Henning, Welcome back!! Looking at the die floor-plans ... the difference in area between 6mm square and 8mm square is·nearly an 80%·increase... that's why the 8mm would fit 16_cogs, and the 6mm would fit only 8_cogs.· I'm not sure that there is an in-between (i.e. a 7mm square) that we could physically fit 12_cogs in without already going to 8mm.· Besides, a much "cleaner" approach is to go with something that is going to be a multiple of 8. ·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Phhh..................I thought I was never going to catch up!
@Chip
This is trully history in the making! Thanks for sharing.
One idea that has been touched on, but maybe not applied to this Simple Speed vs LMM delima!
Keeping the chip small(8cogs).
Serializer/deserializer available to a cog, Loading cog ram from a 8, 16, or 32 bit bus ram chip. A ram chip of your design spicifically for the PropII.
If doable, the prop II could be clean slate, Tap dance around the multithreading, by avoiding hub access for program data, and possiblly lay another piece of silicon on the table that customers not needing it wouldn't have to pay for.
In the end though I don't recall you needing my input to produce such a treasure as the PropI, nor should you place too much weight on our needs and complaints when it comes to implimenting the PropII. I think the answer is in you already, and this is just a test of your·resolution.
bambino said...
...nor should you place too much weight on our needs and complaints when it comes to implimenting the PropII.
That's what's so nice about Chip's approach to user involvement. He listens intently and responds generously, but the final decisions are his to make. A lot of great ideas can be floated and bandied about here in the forum. Some may take hold; some won't. But, when it's all said and done, any synthesis that results will still be the product of — and consistent with — one man's vision and focus, and not a "design by committee". Heaven help the final implementation if Parallax were a huge corporation and we were all on the design team!
Re : Poly fuses ... I think like everything else with the Propeller people will find uses for them well beyond their likely intended purposes ( apart from them being 'general purpose' to start with ). One use I can see is for delivering standard hardware with fuses set to indicate what class of code it is allowed to run, what locale it's in, PAL/NTSC etc.
At the moment, I'm not sure how accessible they will be. The Idea is that for most programmers, this will be a "dormant" feature. When you will want to use them is for code protection, you apply an encryption key (of your choice) that the fuses will be set with. This key must also be used in the IDE in order to download a meaningful program to the Propeller. Successive program upgrades/revisions will be allowed if an OTP fuse switch has not been set and as long as the same key is used in the IDE. This basically prevents or persuades someone from copying the EEPROM and using it with another Propeller Chip. The EEPROM would in a sense be "keyed" into the specific Propeller it was being used with. Moving the EEPROM to another Propeller that wasn't properly keyed would cause the program not to function.
I could be missing some of the details, but that was the general idea of operation using the programmable fuse bits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
If each new cog is more powerful than a whole current Propeller chip, do you really need 16 of them? Would 8 not suffice? Personally, I've never used all 8, except in some demo to show what the chip could do. To me, 8 is quite rich. By the time we get to 16, we are hub-starved and have to resort to cache-line style hub accesses to get the bandwidth back up (well, way up).
Are you guys sure about 16 cogs?
8 cogs on a PropII promises a much smaller footprint and lower cost. For most purposes, I suspect that the 8 cog propII would be optimum; situations that really need more than 8 would be outliers.·Although 16 cogs would always fit more applications, all of·the simpler situations would be necessarily more expensive. Would people want·to buy something that·goes 70% to 80% unused?·This is starting to feel like the problem with sector sizes on hard drives, where·every two byte file begets a huge waste of storage space. Sure it works, but only economies of scale got us to this point.
My critique would be that lush chip capabilities beget wasteful programing and wasteful applications. Falling back to a Forth mindset, a spread out solution indicates poor factoring. A sixteen cog chip would make those more common. One could always design a board that uses two 8cog PropII's if needed, but two 16cog PropII's would be an expensive way to do anything and·might be·better solved using a·DSP.
An interesting question arises: what is the real optimum number of cogs? Could it be as low as five?·Looking at that this morning, I suspect the answer would lie in how multiple chip arrangements are organized. Can the PropII be optimized for·inter-Prop communications?
ps. I still advocate µSD support hardcoded into the PropII so we may boot from a µSD card just as easily as from an eeprom. That's a bigger deal to me than cog count.
Post Edited (Fred Hawkins) : 9/1/2008 9:55:02 PM GMT
Comments
Think I'm crazy? Well perhaps but perhaps also we should generally change the perspective that COG RAM is instruction/memory space.
Lets say it's NOT.
Instead, what we have here is eight 32bit CPUs with 496 REGISTERS each. I mean, WOW amazing !!!
Now, COGs of course are a bit weird in that you have to load an instruction into a register before it can be executed. By default that happens with COGNEW loading everything but it can also be done by some LMM mechanism as in the ImageCraft C compiler etc. Or by some overlay mechanism.
My observation is that many real-time embedded systems have high speed/priority parts which are actually very small and normally allocated to interrupt handlers. The bulk of the code being contained in a background loop that idles around as best it can.
So, given that the high speed/priority parts are small, we see that the need to put large junks of code actually into a COG should be the exception rather than the rule. The bulk of it should be running at a slower pace via LMM or even SPIN as we have now.
The perspective I'm proposing is that we have 1 general purpose CPU (GOG) running 90% of the code and then we have 7 processors handling what would otherwise be interrupts on a traditional system but with the important bonus of timing determinism of dedicated CPUs. Or partition it as 2 to 6 or whatever as appropriate.
Whilst we are at it, this "new" perspective should finally put out of peoples minds the recurring request that COGs have interrupt handling capability. With this view we see that COGs ARE interrupt handlers. But far better, they have timing determinism and we don't have to mess around with interrupt controllers and priority schemes or stacks. All our 7 (or whatever) interrupts are already at the highest priority and none of them need a stack!.
Currently the way COGNEW works and the way SPIN objects are seems to encourage the idea that COGs are general purpose CPUs that we load up with objects but damn they are so small.
I think the view I'm outlining here will become even more relevant with the much higher speed of the PROP II and assistance of it's improved serial I/O to remove the burden of bit banging from actual code.
This view highlights the need for PROP II to enable running LMM code as fast as possible.
Hope I have managed to express this coherently, I'm in a bit of a hurry here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I can´t express it so fine but
Both LMM and say "overlays" I define its "Cogcodeobjects" have its benefits.
LMM for large programs. "Cogcodeobjects" for fast code run if code = INIT+RUN>COG REGS/RAM.
And if "Cogcodeobjects" can solve it INIT reload RUN
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
I see the thing as registers too! It's a lot like just having instructions execute in the registers for the highest speeds. When running LMM, it acts more like a *regular* CPU.
The LMM enhancements being discussed here are going to put the COG memory space problem to rest big time. And the C / LMM PASM programmers are gonna see plenty of performance, meaning you can kind of ignore the COG thing altogether, if you want to.
Another way I see this is that each COG is either a CPU, in the traditional sense, running SPIN or LMM, or it's emulating some hardware (graphics, sound, external memory banking, I/O, etc...). Instead of globbing on a lot of dedicated hardware, you just spend some time in software connecting things together.
I like the focus of tuning the instruction set for LMM / multi-thread. This discussion is going to put most of the current Prop exceptions off the table. Way to go guys!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
I believe they are trying to iron out a task switcher rather than processor threading. Whether it's targetted at just LMM, or both native and LMM, I'm not too sure.
Evan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Is this native Cog code? Isn't the binary register references absolute in native code?
Bit of a squeeze in the Cogs already I thought.
Am I over reacting here?
Night of the living zombie cogs, I see a badly made geek horror movie here [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 8/30/2008 10:18:25 PM GMT
And are there any code examples of the LMM programming language that some here are talking about?
Please forgive my confusion, but I thought that instruction-level task switching was off the table due to pipeline complications and that the TASKxxx instructions were for cooperative multitasking, wherein each task gets to decide when to hand off control. Hence my TASKNXT comment. If the instruction-level interleaving is still doable, that's fantastic! I was ready to be satisfied with less.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Bill Henning originally proposed this (see: http://forums.parallax.com/showthread.php?p=615022). The idea has since been used for a number of things including ImageCraft's C runtime.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Inasmuch as the Propellor I is still so relatively new, I don't think many of us have even really become what could be considered thoroughly competent with it. Consequently, a compatibility and learning curve issue doesn't, in my opinion exist. Go with the flat memory map and make it easier on yourself. After all, it's YOUR baby!
Lil'Joe in Texas
I'm back after many months: getting engaged, going on a cruise, getting married, moving to a house, putting condo on market, setting up in new home...
And what do I see? TONS of progress!
More below:
Paul, I've skimmed over this massive thread, and I love what I am seeing Chip et al propose for Prop II. Here are some initial ideas and feedback, more over the next few days as I digest what has been going on in the forum in my absence.
1) RE: 8 cogs / 256K due to die increase and wanting to have a HUB cycle every eight accesses
That works, however I seem to recall a proposal sometime in the past for a 12 cog design - which would have eight cogs with 1:16 hub cycles and four at 1:8
Cycle COG
0 0
1 8
2 1
3 9
4 2
5 10
6 3
7 11
8 8
9 4
10 9
11 5
12 10
13 6
14 11
15 7
This solves both problems - four cogs get HUB access every 8 cycles, assuming a 160MHz clock, 20M hub cycles per second per clock, reading/writing longs that's 80MB/sec per fast cogs; the eight "slow" cogs get 40MB/sec.... so the fast ones get 4x the current memory bandwidth, the slow ones get 2x
I saw chips "cache line read" idea, while elegant for video renderer, it would complicate LMM's; instead why not add RDDOUBLE/WRDOUBLE - only relatively minor expansion in multiplexers for the hub memory, yet doubles the memory bandwidth shown above; also would be compatible with future 64 bit props [noparse]:)[/noparse]
2) RE: HARDWARE THREADS
I LOVE IT! I think Paul's idea is excellent, let's say only thread 0 has HUB memory access; allows timing to be deterministic for all threads. I'd be tempted to assign WAITVID to a different thread... I will chew on this more. I really, really like this - one cog could easily handle serial + kb + mouse!
3) RE: new addressing modes
offsets & auto inc/dec for hub... EXCELLENT!
indirection cog ram... WAY TO GO!
Way to go Chip, exactly what we need.
4) RE: portA / portB multiplexer
Good idea, frees up a few registers, maybe make the indirection pointers visible instead?
Could we also have a virtual port C? (or V) whose 32 bits we could use for inter-cog faster than hub sync?
5) Ideas I'd like to suggest for discussion:
a) since the port indexing is available, how about using one of the freed up registers to hold the PC and the flags for the current cog?
that would free up some instructions as it would be possible to move new addresses directly into the PC, branch by adding/subbing from it etc
there could be "shadows" of it, one for each thread
b) since there is cog indirect addressing... how about adding another 512 longs of cog memory, to be used as scan line buffers, high speed
sampling buffers, cog based stack et al? I can see soooooo many uses for this its not even funny!
c) an LMM instruction, that uses the auto-incremented pointer to fetch/exec the instruction [noparse]:)[/noparse] saves cog code space
d) I'd love more detail on the new in/out shift registers, I'd really like 10/100mbps ethernet, and at least 12mbps USB without external HW
e) I'd still love a fast single-instruction "replace any byte/word in a register with any byte/word from another"
f) "input mask register" for each port; anded with actual input, would allow for zeroing un-interesting bits in inputs
6) RADICAL IDEA
Who says a byte has to be eight bits?
If PropII was a 36 bit processor, we'd have four new bits per word... two for each address field [noparse]:)[/noparse]
would allow for:
- 2K longs per cog!
- easy 512 color VGA
- more instructions by exposing PC and flags gets rid of some JUMP opcodes
Ok, more later, after I do a LOT of reading to start to catch up. Great to see the C compiler, must play with it.
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Mark
Thanks [noparse]:)[/noparse] Obviously HUB ram would have to go 36 bit... ditto for the rom... I can't be the only one who remembers old machines with 18 / 36 bit words...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 8/30/2008 11:18:47 PM GMT
Welcome back!!
Looking at the die floor-plans ... the difference in area between 6mm square and 8mm square is·nearly an 80%·increase... that's why the 8mm would fit 16_cogs, and the 6mm would fit only 8_cogs.· I'm not sure that there is an in-between (i.e. a 7mm square) that we could physically fit 12_cogs in without already going to 8mm.· Besides, a much "cleaner" approach is to go with something that is going to be a multiple of 8.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
@Chip
This is trully history in the making! Thanks for sharing.
One idea that has been touched on, but maybe not applied to this Simple Speed vs LMM delima!
Keeping the chip small(8cogs).
Serializer/deserializer available to a cog, Loading cog ram from a 8, 16, or 32 bit bus ram chip. A ram chip of your design spicifically for the PropII.
If doable, the prop II could be clean slate, Tap dance around the multithreading, by avoiding hub access for program data, and possiblly lay another piece of silicon on the table that customers not needing it wouldn't have to pay for.
In the end though I don't recall you needing my input to produce such a treasure as the PropI, nor should you place too much weight on our needs and complaints when it comes to implimenting the PropII. I think the answer is in you already, and this is just a test of your·resolution.
I do hope it is still fun for you!
·
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
This is my third or fourth time coming back to this thread and re-reading it ! - and was just thinking the same thing.!
Regards,
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Those who can, do.Those who can’t, teach.
You said.
" There will be several dozen poly fuses for making devices unique, but not enough bits to store any useful code. "
If I had read old discusion on it I have no ask sorry.
It is fine to have that fuses for some who ned scrambling its code. But in my opinion it is waste of time.
Have special Constants on it is very useful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
At the moment, I'm not sure how accessible they will be. The Idea is that for most programmers, this will be a "dormant" feature. When you will want to use them is for code protection, you apply an encryption key (of your choice) that the fuses will be set with. This key must also be used in the IDE in order to download a meaningful program to the Propeller. Successive program upgrades/revisions will be allowed if an OTP fuse switch has not been set and as long as the same key is used in the IDE. This basically prevents or persuades someone from copying the EEPROM and using it with another Propeller Chip. The EEPROM would in a sense be "keyed" into the specific Propeller it was being used with. Moving the EEPROM to another Propeller that wasn't properly keyed would cause the program not to function.
I could be missing some of the details, but that was the general idea of operation using the programmable fuse bits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
It is maybe very crazy idea but.
WAITPEQ and WAITPNE can hang COG/porgram definitely. And many times I know what it must hapen and time to.
My question. It is posible to ad timeout conter and flag to those
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
My critique would be that lush chip capabilities beget wasteful programing and wasteful applications. Falling back to a Forth mindset, a spread out solution indicates poor factoring. A sixteen cog chip would make those more common. One could always design a board that uses two 8cog PropII's if needed, but two 16cog PropII's would be an expensive way to do anything and·might be·better solved using a·DSP.
An interesting question arises: what is the real optimum number of cogs? Could it be as low as five?·Looking at that this morning, I suspect the answer would lie in how multiple chip arrangements are organized. Can the PropII be optimized for·inter-Prop communications?
ps. I still advocate µSD support hardcoded into the PropII so we may boot from a µSD card just as easily as from an eeprom. That's a bigger deal to me than cog count.
Post Edited (Fred Hawkins) : 9/1/2008 9:55:02 PM GMT
One more crazy idea.
In many threds guys postulate to trigger one COG by another by use of 2 propeller pins.
My idea is to incorporate Triger register to fre pins.
All COG´s can write to it but read from it restet only COG´s bit. In that register bit number = COG ID number
Mayby even write trigerbit on counter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 8/31/2008 5:56:30 PM GMT