Future of prop?
P!-Ro
Posts: 1,189
I was just looking at an article from MIT covering many issues about multicore processing. One of the topics was data being pinched by the current hub design and how to fix it, reminding me of some of the limitations to the Prop II, and the main reason why it will only have·8 cogs instead of 16. Interesting article, really. Maybe after a good many years we will see computers running off of this technology, or maybe even the Prop III?
http://www.csail.mit.edu/csailspotlights/feature11
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PG
http://www.csail.mit.edu/csailspotlights/feature11
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PG
Comments
I remember similar discussions and similar proposed solutions for ArcNet and RMS (Resource Management System) which was Datapoint's distributed operating system where up to 255 computers could be networked together along with shared resources like I/O devices, etc. You could set up a workstation where the keyboard and display were at one end of the network. The processor you were actually using for your work was at the other end of the network, and you could attach to disks, printers, modems, etc. anywhere else on the network.
The main reason for only 8 cogs on the Prop II as opposed to 16 is chip area and the costs associated with that. The area occupied by a cog is heavily determined by the area of the cog's RAM and somewhat determined by the area of the execution unit (arithmetic, instruction decoding). There just wasn't room for 16 cogs on a chip that would fit in the range of packages under consideration and the cost for a given chip area vs. the projected price of the finished packaged chip.
http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
http://plan9.bell-labs.com/plan9/
I think the main reason it has 8 COGs instead of 16 is a bit deeper that the size of the cores on silicon or the cost.
When many processors are sharing RAM they are getting in each others way. One way or another they have to have a slice of time allocated to perform their RAM access which is potentially holding up processing.
Consider: If there were an infinite number of processors sharing a RAM the they would all be permanently hung up waiting for RAM access as they have to wait an infinite amount of time for their peer processors to take their turn.
So clearly there is a limit to how many processors it is sensible to have sharing a RAM. That limit probably depends on the nature of the tasks they are performing. That is, on the ratio of time they need computing locally versus the time they need communicating through RAM.
Everyone want's more COGs, but the price of having them is that the maximum speed attainable by any one of them is reduced. I suspect 8 COGs is a good compromise. Would you want to find that you have 128 COGs but, oh dear, all those super fast Prop II COGS can't do ethernet or USB or whatever because of the resulting HUB bottle neck?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
From what I'm told, there are a lot of new products that come out and they don't always last but there are products that have been in production for a while like the Prop I which will be around.· It is always good to go with a design that has been around because you know you will always have it.· You basically want a product that has been around and not always the latest product or the fastest product survives in a market.
Why did the 6502 beat the Z80?· If you are talking a two dollar chip verses a six dollar chip, it costs less money for a manufacturer to come up with.· The Prop II should be positioned effectively against other products which will cost more for less bang for the dollar.
·
Did it? I can't find any sales figures. But that seems to be a big statement considering that you can still buy Z80 compatible processors new from Zilog and they have been used in billions of embedded devices over the years.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Anyway, I would think the volume of the Apple //'s and Commodore 64 outsold Z80 machines. It's just that Z80 machines were more business oriented.
Then along came IBM's PC and because IBM could buy a piece of Intel (they did) they used it in favour over the Motorola 68000. It's not always the best chip that wins!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
there would be 16 times more cogs than currently
but the clock speed is [noparse][[/noparse]hopefully] doubled
instructions only take 1 cycle, so effectively 8 times faster (16 / 8 = 2 -- twice as long to get a long)
but you can do quad long read, so essentially another 4 longs faster per round robin access
this comes out to twice the current longs read over time.
(did I do that math right)?
With the currently anticipated setup, we should be able to read 32 times more longs per second than we are able to right now.
Of course this is for PASM, but that should really be the main area where we care about speed. SPIN is their to make our life easy, not to give us Gbytes of bandwidth.
I think that it is a price/size issue as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!
Some of my objects:
MCP3X0X ADC Driver - Programmable Schmitt inputs, frequency reading, and more!
Simple Propeller-based Database - Making life easier and more readable for all your EEPROM storage needs.
String Manipulation Library - Don't allow strings to be the bane of the Propeller, bend them to your will!
Fast Inter-Propeller Comm - Fast communication between two propellers (1.37MB/s @100MHz)!
I see I was hopelessly optimistic about that.
Let me be the first to ask "Any word yet about Prop IV?".
My brother's Sinclair ZX Spectrum(Timex Sinclair something in the USA) could hardly be called 'business oriented', even if Wordprocessors and databases were available.
(We have Tasword 2 laying about somewhere, still)
Also, I remember that Sir Clive got a special white ZX Spectrum when they hit 1.000.000 sold. And final numbers were closer to 2million, I believe.
That's not counting the ZX80 and ZX81 models, the later 128K models, the Cambridge Z88 laptops(new company)
Nobody knows exactly how many copies of the ZX Spectrum was built in the USSR back then...
http://en.wikipedia.org/wiki/List_of_ZX_Spectrum_clones
They still have a 'rather large' following, though.
There was even a model 'Sprinter' which used a PLD in conjunction with the Z80 to emulate other clone models...
http://www.nedopc.org/nedopc/sprinter/index.shtml
Heh, even my old Casio labelwriter uses a Z80...
And one day I'll rip out the ROM, disassemble it and find out the serial protocol on it. Darn those nefarious Casio people for not giving me the specks when I asked politely...
BTW: I heard that the Zilog Z8000 was one of the contenders for the IBM PC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
IMHO, 6502 won out for good timing, and its cost, simplicity, and overall speed. When moving data, a Z80, or 6809 will clean up big. No question there. For the most part, on compute the same is true, particularly on the 6809, with it's hardware multiply, and multi-byte push and pull instructions, competing nicely with Z80. (I think 6809 is superior to Z80, but I've also not done as much on the Z80, so it's just me probably.)
The 6502 was released at a fraction of what the other chips cost, were available, and ended up in the Apple, CBM, Atari, and other systems.
People picked up on those and influenced the market, even as the cost of the others came down.
Over in UK, Z80 hit the sweet spot there and was much more common.
IMHO, the 68x and 65x chips operated well with lower clocks too, influencing some decisions. Z80's need a higher clock, and that meant cost back then. Still does.
BTW: The lower clock capability of the Prop is one key factor to it being as easy as it is. All the tough signals are inside the box!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Yeah, multi-register push and pop with the dual stack pointers can move a lot of memory very quickly
(for an eight-bit micro).
I cut my teeth on the 6809, both on the CoCo and on a SWTpC running OS/9 (Level 1, with multiple
terminals and multiple users).
The 6809 was such a clean little chip (except maybe the flags). I wore out more than one of those
opcode cheat cards.
It was mentioned that it was space issues among other things that prevented 16 cogs in the prop II: That may be true, but although I may have mislabeled the bottleneck problem as the primary, I know it was brought up a while ago, probably in the thread "Which do you want more of, cogs or ram?" The only reason I pounced on it was because the article was about preventing this bottleneck effect, and I saw a correlation.
It was also mentioned that I was overly thinking about the Prop III (sylvie). I just brought it up because I can see a future of programming 100+ core micros for robotics, a field I hope to go into as a career. Since I might as well on the propeller forum, why not call it the Prop III, even though it won't be anything like what I can envision now? Might as well, what else would I call it? But I definitely do find the prospect with working on plenty of cores intriguing. Good thing I'm working with the Prop I to start off with, eh?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PG
That would buy a hundreds++ of cogs and plenty of cog (banked ram) and hub ram !!!
Suggestion for the Prop III... 32 cogs, each with banked ram (say 8KB) and hub ram could be supplemented via an external fast DRAM bus.
Anyway, we have the Prop I now, it is reasonably priced, low power, and we are extending it's abilities on an almost daily basis.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
1) Prop III should have 64 bit COGS. That allows 25 bit source and destination fields in the instructions and therefore a directly accessible COG register space of 32M LONGS. No banked register space. We hate banking.
3) Given all that possible COG space, dump the HUB RAM entirely.
4) Have some kind of direct communication between COGs.
4) Each COG would have the possibility of configuring a bunch of I/O pins as an external bus interface. Not all that 64M LONG register space would be in the COG necessarily.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Anyway, yes and no:
1) My fantasy Prop III still has the mind bending simple, uniform and elegant instruction set of the current Prop. Just much wider.
2) With an optional, configurable external bus interface on the COGs the actual on chip COG space need not be 32M LONGS, which is unlikely to be, but it will be able to execute code from external RAM.
3) I might make COG to COG communication much simpler, Just arrange that LONGS or "LONG LONGS" can be written to a special address in one COG space and they are then visible in all the other COG spaces.
Probably need some of the MIT guys optical interconnect to pull that last one off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
- as written before, a mailbox system or shared memory for inter-COG communication would be very, very helpful.
This kind of self modifying assembler is remembering me in old Z80 times (my first TRS80, forgotten in the discussion above)
Mr. Allens and Mr. Gates Basic interpreter there was doing such ugly things..but now they are very rich guys. So maybe Parallax has the same strategy
- a simple setbit / clrbit also in assembler
- an USB host port, for all the consumer and data collecting things, or at least an extra USB chip simpler and more reliable then the FTDI host chip
for Prop III
- for all COG collectors, a link like the Transputer link for cascading COGs over several Propellers
- the Propeller or multiples of them as IP for any FPGA, or as a hard wired core for a FPGA
- and a FPU , this would be really great, no other small uP has it....
When there are interconnects between the COG's directly, those scale more than the COGs themselves do, consuming die space and generating a lot of heat.
Seems to me, an optimal direction to go would be a Propeller with HUB memory on chip, for bootstrapping things, and for those times when more RAM is not needed has a lot of advantages. For a larger memory model, on-chip logic then allocates a bank of pins to interface with external memory. A request from a COG gets address translated, then data either gets copied to the COG, or data is written to that address in external RAM.
Each COG then can access that external memory, through the memory control logic, which is shared round robin, as the HUB memory itself is.
That's the key multi-processing / multi-core element of the Propeller, in that it simplifies and makes the cases of shared data between compute nodes consistent and deterministic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Computers are microcontrolled.
Robots are microcontrolled.
I am microcontrolled.
SX Spinning light display·
http://designedbymemicros.blogspot.com/
It's always bigger, better, faster...
The beauty of it here in Propeller land is that we have Prop I, it's done, and will be available for a very long time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Don't you know that the 'Coanda' (codename for the Prop IV, and named after Henri Coanda, the first to use jet power, in 1909... ) will have built-in RGB LASER LEDs and the capacity to synch them with the spin of rotatingmirrors, so that it can generate full-colour 3D holograms?
No lenses will be necessary as one of the Propellerheads here will realise that he can set up 4 counters for each colour to rapidly pull IO-pins to high and low, so that the power-fluctuations causes localized contracions and expansions in the material around the LASER LEDs...
The gamepad is still needed... Until 'Kitty Hawk' arrives with more LASERs and someone manages to use one LASER LED and what looks strangely similar to the 'resistor and caps ADC' in use on the Prop I projects, to read the reflected light of a virtual keyboard projected with the red LASER onto a 'reasonably flat' surface.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
But while we are talking about it, I think it's true that without a hub a Prop just can't be a Prop. It just can't have that spinning motion. So what else could it be called with interconnected cogs, Spiderweb I? And yes I agree, talking about it is pointless [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PG
@potatoehead: communication links between cogs don't have to take up much die space or power. Take a look at the 40core SeaForth chip. It has up, down, left and right 18bit links for each core, and it runs very low power. If it wasn't for the goofy 18bit architecture, expensive programming kit, and overmoderated forum, I think this chip would be great to program. If the Propeller had the cogs arranged in a grid as well and had 4 32bit links to the neighboring cogs, you could have a lot more cogs without starving the cogs for bandwidth from the hub. Neighboring cogs could just pass their bandwidth to the one that needed it through the ports.
I agree, a prop without a hub is not a prop, but the real thing that keeps the prop deterministic is the clock and the lack of interrupts. I too would like to see a hub with an external memory interface, and some cache that could be used directly if you didn't want to wire up external memory chips.
I still miss the B port Prop. 64I/Os would be great. Even if you didn't need them, you could use them for ports between cogs.
I am also amazed by what the OMAP3530 chip can do with such little power and space. I have been looking at the beagleboard and the IGEP. The up and coming OMAP4 is supposed to have 2 cores. I wonder how they are going to communicate.
There is a lot of complexity in programming that goes away with this design. From what I've seen of other multi-processor, multi-core chips, the additional options do make niche cases possible, and in those niches provide good performance, at the programming penalty of greater overall complexity in both the management of those I/O facilities, and integration of core "objects".
Both of these things are very lean on Propeller, and frankly, that's worth a lot. If it were not, I seriously doubt many of us would be here, as the design wouldn't be differentiated enough from the others to provide the momentum it does.
Sorry, but the core elements of how a Propeller works are not easily dismissed. As compelling as that niche case is, the dilution of the overall lean Propeller design packs a great punch, and is something I have no desire to see compromised.
It's possible to weave rather complex bits of code together on a Propeller, regardless of how they interact with the shared memory. Direct interconnects will not exhibit that same property, and this is quite possibly the primary reason many people use the chip. I know it matters to me, as I'm just not a systems level programmer. I know lots of people this way, who don't want to write mini operating system kernels just to make their little widgets go, show a display, and such...
Finally, if I am not mistaken, I do not believe I've seen the broad range of capability demonstrated, and more importantly, utilized by such a diverse audience, with either the ease or depth that is seen on Propellers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 1/28/2010 4:05:37 AM GMT