In terms of break out apps... I think we are going to see lots of them. What I love about the Prop is that I don't have to worry about anyone else's abstractions and if I need one, I can always ask for it. The guys here can chew them up and spit them out with the best of them!!!
With the Prop you can start a good mental picture of what you want and work backwards, from the primary architectural constraints to get to a real world solution... you can't do that very easily with any deeply abstracted architecture, unless you happen to control the abstraction.
And the breadkout apps can come from anywhere. My money is still on the Russians, but I wouldn't count the Chinese out of this quite yet.
By the way, my first recruit is now attempting to learn Mandarin, so if anyone has some well translated multi-Propeller based texts in Mandarin, with a reasonable English translation, please post.
When you write in a high level language you do not really care what the architecture of the hardware is.
(why hippy is not·in game biz)
Performance matters. Getting things done does too. Fast low level bit banging around here has primacy. Using the other guy's objects well is good too.
I'm starting to wonder if we'll start to see n cogs processing the nth bit of a fast stream.
When you write in a high level language you do not really care what the architecture of the hardware is.
(why hippy is not in game biz)
Performance matters. Getting things done does too. Fast low level bit banging around here has primacy.
I did prefix my comment with "most programmers", and games programmers and what we do here, often as low-level, high-speed, bit-bangers, is I believe the minority sport.
Most programmers I believe are happy enough if the end result runs fast enough to deliver what needs doing. They might tweak things to make their code faster, but that's not usually their primary focus.
Well, shoot. I thought we were talking amongst just us chickens. Now you go and bring all those other birds...
I'll admit some are prettily colored. Ruby on Rails, anyone? Or quaint, Pascal? But on every platform I've owned, success came with making the hardware sing.
Not that I was the guy. I just bought stuff. Still do, mostly from smart Aussies that understand oLEDs and characters in Calif with jobs to die for.
Computing has the task of processing data: 0 0, 0 1, 1 0, 11: little processing of few data, little processing of many data, much processing of few data, much processing of many data.
That is an abstraction: 2 bits allow for 4 items.
The propeller allows for much processing of many data, if only much is not to much and many is not to many too.
The race to build the first non-Proprietary, Parallelized, Parallax Propeller SuperController has officially begun. And this is a race that everyone will win, all the way from the boondocks of Ohio to the ski slopes of Sidney!
correct,
That used to be in my agenda and you'll see in my earlier posts to this thread
that I had suggested the reset-daisy-chain etc. a long time ago.
I concluded that a chain on reset took excessive time and was prone
to single-point of failure if any prop malfunctioned - all
subsequent ones would not come up either.
I would like a solution that would communicate using a loose mesh,
perhaps getting-around one or more connector failures. [noparse][[/noparse]the bane of robotics]
I did not go for the common clock for nearly the same reason.
Right now its better if those working on it ( getting multiple
props connected and up ) get to the point that they boot and self-enumerate
without needing a 'master' anything anywhere in the mix.
My own solution was to realize that timing sync issues
could be separated from booting issues and this decoupling
would allow "clusters" of props to "share" all kinds of sensors
and peripherals (not just clocks and EEprom).
Hello all.· I am new to the forum and new to the propeller chip.· I was researching ways to do video with a microcontroller, and the propeller came up in my search.· Once I started reading about it, I was fascinated with the multicore design.· I've always had an interest in parallel computing but have not been able to pursue it.· The design aspects of ganging these chips together are very exciting.· I hope to contribute materially·to the theory and design of such a thing at a future point.· I like to think that I can come up with some unique designs of my own, but am currently researching the current state of the art.· Much work has been done, and there's no point reinventing the wheel.· I actually spent about two hours reading this entire post.· No offense to those discussing related issues of computer science and parallel computing, however, I think Chip's original query as to how to actually implement such a design has lost attention in the thread.· I'll be putting in some ideas here and there as this thread develops.· I'd love to see a poor man's parallel computer, as it were, with, say, 50 - 500 cores.· Ganging 8 chips together would allow 64 cores, a very nice start.· I'm going to throw out some ideas, but first the caveats.· I have an electronics degree from 20+ years ago, and a significant interest in parallel computing.· I've programmed simple microcontrollers of the '80's and '90's vintage.· I am now looking into the PIC32 from Microchip, as well as the·Propeller.· I'm not a parallel computing expert either, so if I say something obvious or impractical, please forgive.· I was giving some thought as to an architecture which would be helpful to build the poor man's parallel computer.· Based on my (minimal to this point) research, it seems the biggest issues preventing implementation are inter core communications, maintaining data consistency, parallizing the program, and development and debugging.· I was·thinking about the communication aspect in particular, when I ran across a company which is already way down the road in developing around all these issues.· Take a look at http://www.ambric.com/·and the white paper at http://www.ambric.com/pdf/JPEG_VideoImagingDesign_combined_final.pdf·.· This information is very intriguing.· They have developed a single chip with 300+ cores on it.· Each core is completely independent with its own memory and self synchronizing high speed communications channels.· They have a complete development·and debugging environment for the parallel architecture.· The design promises 1 TRILLION operations / second for 12 W of power.· I think it would be great to incorporate this type of technology in a multi Propeller design running at say 4 BIPS, as much as can be done so without violating patents.· This level of processing power would be somewhere in the range of a typical general purpose dual core or quad core chip if my math is right; but it would have·the advantage of the parallelism.· Alternatively, perhaps Chip could license the technology and make some form of it available to us.· I'd love to know what everyone thinks of this idea.
Comments
Fred,
In terms of break out apps... I think we are going to see lots of them. What I love about the Prop is that I don't have to worry about anyone else's abstractions and if I need one, I can always ask for it. The guys here can chew them up and spit them out with the best of them!!!
With the Prop you can start a good mental picture of what you want and work backwards, from the primary architectural constraints to get to a real world solution... you can't do that very easily with any deeply abstracted architecture, unless you happen to control the abstraction.
And the breadkout apps can come from anywhere. My money is still on the Russians, but I wouldn't count the Chinese out of this quite yet.
By the way, my first recruit is now attempting to learn Mandarin, so if anyone has some well translated multi-Propeller based texts in Mandarin, with a reasonable English translation, please post.
Rich
Performance matters. Getting things done does too. Fast low level bit banging around here has primacy. Using the other guy's objects well is good too.
I'm starting to wonder if we'll start to see n cogs processing the nth bit of a fast stream.
Of course. I'm not sure how else to do a jpeg to HDTV driver*.
Not that it works yet.
Yours, Tom Perkins
*Pre-processing the jpeg into separate per bit per pixel operations slugs of data seems like it might be productive. If it works I'll know.
I did prefix my comment with "most programmers", and games programmers and what we do here, often as low-level, high-speed, bit-bangers, is I believe the minority sport.
Most programmers I believe are happy enough if the end result runs fast enough to deliver what needs doing. They might tweak things to make their code faster, but that's not usually their primary focus.
I'll admit some are prettily colored. Ruby on Rails, anyone? Or quaint, Pascal? But on every platform I've owned, success came with making the hardware sing.
Not that I was the guy. I just bought stuff. Still do, mostly from smart Aussies that understand oLEDs and characters in Calif with jobs to die for.
That is an abstraction: 2 bits allow for 4 items.
The propeller allows for much processing of many data, if only much is not to much and many is not to many too.
We know who our friends are[noparse]:)[/noparse]
Especially being able to load multiple Props in parallel. There's a guy over here http://forums.parallax.com/showthread.php?p=758971 who needs to know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I believe Chip is still interested in supporting arrays
of props (but I will let him speak for himself).
I'm working my way up to demo here several related concepts;
each building on the foundations laid by the ones that came before.
Working thread titles:
- C multi-tasking - go beyond 8 cogs without thread headaches
- C programs larger than 32K with an hx512
- fishing without a license? ignore your limits!
aka: use an SD card and allow 2gig memory for your C app
- putting events, exceptions and "interrupts" into a C application
... without giving up strict control of timing
- mufflers, meters, valves and jets - pipes on steroids
(or live-sockets) to couple your cogs
- persistent memory - transparent saving
of hub data back to the an EEprom
- persistent memory II - restartable programs and
crash-only software
- persistent memory III - restartable pipes!
- grow your own OS in C, be your own boss!
- C objects that can be "run" by any cog in a storm
... delayed binding and "thunks"
- what good is a bad pointer?
- how real estate issues relate to Prop connectivity
... and how DNS can help point the way to a solution
- the great YAML vs JSON vs serialize() debate...
... and how apps in C on a Prop can win either way
- access to memory in other cogs - even in other Props!
- distributed computing, content addressable cogs
- Subsumption architecture in C on a Prop or three
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That used to be in my agenda and you'll see in my earlier posts to this thread
that I had suggested the reset-daisy-chain etc. a long time ago.
I concluded that a chain on reset took excessive time and was prone
to single-point of failure if any prop malfunctioned - all
subsequent ones would not come up either.
I would like a solution that would communicate using a loose mesh,
perhaps getting-around one or more connector failures. [noparse][[/noparse]the bane of robotics]
I did not go for the common clock for nearly the same reason.
Right now its better if those working on it ( getting multiple
props connected and up ) get to the point that they boot and self-enumerate
without needing a 'master' anything anywhere in the mix.
My own solution was to realize that timing sync issues
could be separated from booting issues and this decoupling
would allow "clusters" of props to "share" all kinds of sensors
and peripherals (not just clocks and EEprom).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
Sincerely,
Ron