Seriously, this topic's occasional spurts of life may give false encouragement to those who imagine there's still time to influence the Prop II's design. OTOH, the thread is a convenient common bucket into which the entrails of vain hope, unrequited desire, rampant rumor, and idle speculation can be tossed. So I guess it still serves a purpose, despite its overripeness
How about a melting pot of ideas......................useful, or not.
I heard that the new Prop ][noparse][[/noparse] will only have:
#1. one COG, but 16 interrupts
#2. using the new "Linear Bit Stacking Bubble Memory" where the bits are actual bubbles that are stacked UPWARDS together...shifts are done by popping bubbles. A micro compressor is provided using Muscle Wire to create air flow to create new memory bubbles.
#3. Binary logic has been enhanced to support the logical "maybe" state...so now we can support, "true", "false" and "maybe"
More info to come as I get it directly from Chips head via a tinfoil hat I wear outdoors...
While I would have absolutely loved floating point hardware, it is entirely possible to implement a very sexy 2D and even 3D graphics systems using relatively slow hardware and fixed point notation (and trickery).
I suspect that you can actually come up with a pretty decent triangle rasterizer (in 3D) (up to and including Gouraud (sp?)) shading using the prop v1 (certain functions, such as shade will, naturally, need to be asm). Also obviously, fixed point arithmetic is a must in such a situation.
I'd actually like to do this as a proof of concept, but I just haven't had the time.
The point is though, despite our love of floats, there were years and years of processors without hardware FPUs that did amazing things.
There is no ETA, nor is there likely to be any. Parallax does not provide them. They understand that unforseen circumstances happen and a public ETA leads to pressure to produce a product with flaws.
There will not be a DIP package. There will probably be several surface mount 80 pin packages.
There will not be interrupts. One of the major assumptions in the creation of the Propeller is that, with multiple processors, interrupts would not be necessary. One of the very useful aspects of the Propeller is that the instruction timing is completely deterministic. Interrupts would make that impossible. It's possible (and pretty easy) to synchronize multiple cogs so their timing relationship is known, even in the presence of access to shared memory through the hub.
Propeller II already will have more cogs (16) and more ram (256K hub + 2K per cog).
Ah, just a thought, MRAM is still ramping up via older fabs at the moment. Maybe suitable for building a low power device like the PropellerII. [noparse]:)[/noparse]
The really neat part about this, assuming my assumption is right so far, is that MRAM has a much smaller feature size than SRAM. Wouldn't need such a large chip then. I'm also assuming that these fabs are not in great demand and would welcome a novel chip design through their doors.
How about adding or making the rom fonts more lcd friendly?
A half sized font would be handy.
Another thing I have thought about is some slight changes to the font to allow 1 of every so many lines to be used with a smaller font such as a 5x8. As it is now you have to create these fonts and leave them use up memory.
You mean the fonts ?, of course. WIthout wasting too much space in a small and low res LCD. Look I was using a 640x480 LCD as 640x240 (memory constraint). The default font was ok, a bit big maybe but very readable. I changed the resolution to 320x240 (same size) and those where BIG numbers, way too big. Something like 12x8 looks much better. A 8x8 font would have been ideal, so I draw one myself (looks like the one in the Spectrum) it took some space in COG RAM that I needed so I moved it to HUB RAM... Still plenty but that could have been .. avoided. So far from the built-in info I use the Sine table (see FFT article) and the Font (besides the interpreter/bootloader/usw.).
So they could add a couple of different size fonts 5x7, 8x12 and the big and very good looking 16x32.
I was really surprised to find out that there was no place to plug in say an 8 gig flash drive or such. I have to go with ram. It doesn't have to be built in, just a way to use it.
There already is a way to use an SD card up to 2GB (beyond that requires use of proprietary Microsoft file system stuff with licensing fees, etc.) with the existing Propeller. Just download the FAT File System object from the Propeller Object Exchange. All you need is the SD card socket and four I/O pins.
i had an idea for a "conditional accumulator bit". for example, instead of if_z, or if_c, you would have if_true or if_false.
the idea is that you could AND/OR the Z bit and C bit with the accumulator.
for example:
also, the conditional accumulator bit could be automatically pushed to a stack with calls, or a "pushc" bit could be encoded in the instruction set alongside a popc bit, which would operate the "c-bit stack".
Post Edited (Lee Marshall) : 10/29/2008 2:50:40 AM GMT
Erik Friesen said...
How about adding or making the rom fonts more lcd friendly?
A half sized font would be handy.
Another thing I have thought about is some slight changes to the font to allow 1 of every so many lines to be used with a smaller font such as a 5x8. As it is now you have to create these fonts and leave them use up memory.
Assuming that the chip design is already far - it might be too late to comment the original question presented at the beginning of this thread.
Sill I would wote for more COGs and less memory (if you cannot have them both - ofcourse). The reasons are:
- most software problems are easier to solve by dividing them into smaller units = more COGs
- on overall, a algorithm solved on one COG probably uses totally less instructions if divided upon two COGs
- this would benefit mostly fast applications running PASM
- there is enough RAM for mainnly PASM based applications as long as the main ram is at least double the size as the total size of COG register space
Hub access in a round-robin fashion is nice, predictable and symmetrical. I would wote for a system where you could three selectable modes:
1. Hub accesses are granted in a circular fashion (as int the current propeller)
2. Hub accesses are granted in a priority order (then lowest cog number always gets immediate access, the next one must wait for one access period - if hub is occupied...and so forth)
3. Hub accesses are granted in the order of how they are requested, in other words, the hub is waiting for an access and grants the access to the first bidder (still following the priorit order in case 2 -if there are simultaneous access requests).
There modes would not be too hard to implement in hardware either (being an hardware and FPGA designer I think that I can claim that).
Just leaving the HUB accesses "rotating" as in case 1, would be a waste of bandwidth. Typically just a few of the COGs need fast bandwith to central memory, and having the priority decoridng as in case 2 would guarantee that certain COGs always have a certain bandwith with the HUB memory. And the total HUB memory thoughput would be dramatically increased. This scheme would work even if multiple COGS are running SPIN. COGs with the smallest number would run with the highest bandwidth, and less speedy tasks would run slightly slower on higher numbered COGs...
Just a couple of my thoughts.
Christian
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The future does not exist - we must invent it!
For a while, with an increased 6mm2 die size, 16 Cogs and 256kB of Hub RAM was on the cards. But, I think, the quad ported Cog RAM made 16 Cogs too big to fit in even that space. It's back to 8 Cogs now but they are going to be notably more powerful and extra support being added for Large Memory Model(LMM).
The concern over Hub bandwidth is also sorted with an extra wide bus and buffering hidden under the Hub instructions.
Unfortunately it is I believe 8 cogs with 512x32 and hub ram 256KB (32Kx32). The quad port ram to each cog took up too much space so the extra cogs went. :-( The cogs are expected to have much improved counters and some extra instructions. Instructions are expected to be single cycle (effective due t pipelining) so much faster. Also faster and wider hub memory access.
Chip, ··· 16 cores please. ··· First of all - thank you.· You have done us all a very great service by intruducing the 8-cog Propeller I, I find this existing parallel processor amazing. ··· I vote for more embedded processors·- 16 would be a good start.· I will await your beta release of the new Propeller II either way. ··· /michael
With the extra support being added for Large Memory Model(LMM) and the larger Hub RAM there will be multitasking executives that could run many tasks per core and with friendly compiler support to boot.
I don't think anyone will be disappointed with the PropII being an 8 Cog micro controller.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
How about a melting pot of ideas......................useful, or not.
#1. one COG, but 16 interrupts
#2. using the new "Linear Bit Stacking Bubble Memory" where the bits are actual bubbles that are stacked UPWARDS together...shifts are done by popping bubbles. A micro compressor is provided using Muscle Wire to create air flow to create new memory bubbles.
#3. Binary logic has been enhanced to support the logical "maybe" state...so now we can support, "true", "false" and "maybe"
More info to come as I get it directly from Chips head via a tinfoil hat I wear outdoors...
~Kam (^8*
I thought it was going to have quad state logic i.e. "true", "false", "maybe" and "forked if I know" [noparse]:)[/noparse]
While I would have absolutely loved floating point hardware, it is entirely possible to implement a very sexy 2D and even 3D graphics systems using relatively slow hardware and fixed point notation (and trickery).
I suspect that you can actually come up with a pretty decent triangle rasterizer (in 3D) (up to and including Gouraud (sp?)) shading using the prop v1 (certain functions, such as shade will, naturally, need to be asm). Also obviously, fixed point arithmetic is a must in such a situation.
I'd actually like to do this as a proof of concept, but I just haven't had the time.
The point is though, despite our love of floats, there were years and years of processors without hardware FPUs that did amazing things.
There will not be a DIP package. There will probably be several surface mount 80 pin packages.
WTB interupts and of corse Both more cogs and ram.
Cheers
TJ
·
Propeller II already will have more cogs (16) and more ram (256K hub + 2K per cog).
The really neat part about this, assuming my assumption is right so far, is that MRAM has a much smaller feature size than SRAM. Wouldn't need such a large chip then. I'm also assuming that these fabs are not in great demand and would welcome a novel chip design through their doors.
Evan
A half sized font would be handy.
Another thing I have thought about is some slight changes to the font to allow 1 of every so many lines to be used with a smaller font such as a 5x8. As it is now you have to create these fonts and leave them use up memory.
256Kb is a way different scenario compared to the 32Kb we are using right now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
So they could add a couple of different size fonts 5x7, 8x12 and the big and very good looking 16x32.
the idea is that you could AND/OR the Z bit and C bit with the accumulator.
for example:
cmp number,#3 WZ
cmp number2,#7 ANDC
if_true call routine
if_false call another_routine
also, the conditional accumulator bit could be automatically pushed to a stack with calls, or a "pushc" bit could be encoded in the instruction set alongside a popc bit, which would operate the "c-bit stack".
Post Edited (Lee Marshall) : 10/29/2008 2:50:40 AM GMT
' if (x == 3 and y < 7) ' routine() ' else ' another_routine() cmps x,#3 wz cmps y,#7 wc if_c_and_z call #routine if_nc_or_nz call #another_routineOf course, routine has to preserve c and z for this simple example to work. Otherwise, it will be necessary to add some jumps.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
http://forums.parallax.com/showthread.php?p=708332
But it would sure be nice to have some minor changes in the font layout to make it easier.
or, a dedicated RAM cache for the graphics display.
Jim-
Assuming that the chip design is already far - it might be too late to comment the original question presented at the beginning of this thread.
Sill I would wote for more COGs and less memory (if you cannot have them both - ofcourse). The reasons are:
- most software problems are easier to solve by dividing them into smaller units = more COGs
- on overall, a algorithm solved on one COG probably uses totally less instructions if divided upon two COGs
- this would benefit mostly fast applications running PASM
- there is enough RAM for mainnly PASM based applications as long as the main ram is at least double the size as the total size of COG register space
Hub access in a round-robin fashion is nice, predictable and symmetrical. I would wote for a system where you could three selectable modes:
1. Hub accesses are granted in a circular fashion (as int the current propeller)
2. Hub accesses are granted in a priority order (then lowest cog number always gets immediate access, the next one must wait for one access period - if hub is occupied...and so forth)
3. Hub accesses are granted in the order of how they are requested, in other words, the hub is waiting for an access and grants the access to the first bidder (still following the priorit order in case 2 -if there are simultaneous access requests).
There modes would not be too hard to implement in hardware either (being an hardware and FPGA designer I think that I can claim that).
Just leaving the HUB accesses "rotating" as in case 1, would be a waste of bandwidth. Typically just a few of the COGs need fast bandwith to central memory, and having the priority decoridng as in case 2 would guarantee that certain COGs always have a certain bandwith with the HUB memory. And the total HUB memory thoughput would be dramatically increased. This scheme would work even if multiple COGS are running SPIN. COGs with the smallest number would run with the highest bandwidth, and less speedy tasks would run slightly slower on higher numbered COGs...
Just a couple of my thoughts.
Christian
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The future does not exist - we must invent it!
Check out the much more recent Should the next Propeller be code-compatible? thread. There is much discussion about 8 vs 16 Cogs.
For a while, with an increased 6mm2 die size, 16 Cogs and 256kB of Hub RAM was on the cards. But, I think, the quad ported Cog RAM made 16 Cogs too big to fit in even that space. It's back to 8 Cogs now but they are going to be notably more powerful and extra support being added for Large Memory Model(LMM).
The concern over Hub bandwidth is also sorted with an extra wide bus and buffering hidden under the Hub instructions.
First it was 16 cogs, then somebody decided it was going to be 8 cogs.
Now back to 16 cogs again?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
I expect any comments now are probably too late.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adequatio Rei Et Intellectus
How many COG's planned in Propeller II now? 16 or 8 COG's?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
MultiCOG - realtime multicore systems
··· 16 cores please.
··· First of all - thank you.· You have done us all a very great service by intruducing the 8-cog Propeller I, I find this existing parallel processor amazing.
··· I vote for more embedded processors·- 16 would be a good start.· I will await your beta release of the new Propeller II either way.
··· /michael
With the extra support being added for Large Memory Model(LMM) and the larger Hub RAM there will be multitasking executives that could run many tasks per core and with friendly compiler support to boot.
I don't think anyone will be disappointed with the PropII being an 8 Cog micro controller.