Propeller 3 Spun Up Yet?
tryit
Posts: 72
Now that the prop-2 is inevitable, any plans for a prop-3? Will it be a single-board-computer like the R-Pi and Beaglebone? Will you design a CPU from scratch, or merge the prop-2 with an existing CPU?
Comments
As I said before, focus on the here and now.
The Propeller III will have 64 bit COGS. 128 of them.
With the increase to 64 bits the instruction src and des fields become 25 bits each thus allowing COGs with 64 mega registers or 256 mega bytes.
COG memory will reside in a memory chip mounted on top of the CPU chip, Package on Package style, like the Raspberry Pi.
HUB RAM is removed, no need for it with such big COGS. Replaced by high speed data channels between the COGS, in a toroidal grid topology.
Running at 4GHz the PIII will easily run any Linux distro or BSD or whatever you like. Up to 128 instances at the same time. Who needs virtual machines when you have real processors?
64 bit floating point support will of course be supported in hardware thus allowing super fast running of JavaScript under node.js
Supplied in a 10,000 pin BGA package I/O should not be an issue.
Might not be suitable for operation from batteries.
9 bits plus 16 extra we are going to get per field is 25 bits of address.
That is 2 to the power 25 addresses = 32 binary mega WORDs
A WORD is now 64 bits or 8 bytes so the address space in bytes is 8 * 32 mega = 256 mega bytes.
So yes, looks like you are right. But then that is the same as my final result anyway !
On the other hand in Moore's Law we trust.
In the early 1980's we were working with 8 bit CPU's and kilo bytes of RAM. In 1K 4bit wide packages.
Looking at the billions of transistors in my desktop CPU now, the giga bytes of RAM and tera bytes of storage we can see how progress has been going.
The guy who designed the Epiphany chip in the famous Parallella machine now has sixteen 32 bit floating point cores in there. Wired in a topology as I described. I believe they have just released their 64 core design. He is confident that thousands of such cores will be possible within a few years and I got the idea for putting the RAM on top of the CPU from him.
None of this is out of the bounds of possibility.
Given the length of time it takes to get a Propeller chip designed if such a design were started now the technology to build it may well be ready when it's done. That is 3 or 4 "Moore times".
256MB cog memory is too low for the linux, so:
cog memory will be built-in the chip
16 GB of hub memory will be mounted on top of the cpu
Running @4 GHz at turbo speed, but can run @160 MHz in battery mode using less than 1 Watt
BGA will be no problem, a board with some GPIO pins, maybe 512 of them, will be produced
A mad dream of the microcontroler hobbyist
No, 256MB is quite enough for Linux. I am running Linux on many devices with only 32MB RAM. Most of that is not used. Heck this old laptop I'm making this post with only has 512MB and it's running X Windows and KDE as well as the monstrous Chrome browser!
As I said HUB memory is no longer required if you have BIG COGS. Those intercog communication channels are though.
@rod1963, Now perhaps. Point was that Adeapteva had already designed and built their chip when they went to Kickstarter to get the money to build the board to put it on.
The later funding is more an investment in future bigger better chips.
I agree, but 10,000 pins will not be a problem. Vcc and Vss will be sufficient, as this prop will noise induced start to think about the bright shining future of itself and show autistic behavior ;-)
How does one represent the word 'ambition' in Chinese?
Two characters. 'wild' + 'heart'
64 bit floating point? Good to that last decimal (wherever that might be).
As long as it has Forth, I'm good. I already have enough Linux machines.
Why not?
Every one dollar MCU does 32 bit floating point today.
For my fantasy Propeller III that is the least we can expect.
Besides, for that "no operating system, interactive command line interface" JavaScript is great. Just so happens that the only numbers JS understands are 64 bit floating point, which is also good for 53 bit integers, better than the usual 32 bit ints.
Point I was trying to make, is that Parallela has the sort of experience and money that Parallax doesn't have. And IC design and testing is very expensive as Parallax has found out pouring over $4 million into the P-2 and having nothing to show for it, except two failed designs with no timeline when the new design will be done and ready for a shuttle run.
I simply think we should be grateful when we get a P-2 and understand Parallax isn't Intel or Microchip with a stable of top IC designers and computer architects at their disposal who can churn out new designs like clockwork. Not to mention that a P-3 is dependent on the P-2 being a good seller before Parallax can even commit to it and there are no guarantees that that they can sell the millions they need.
Personally I'm more interested in how the P-2 will turn out, I have a couple of designs I'd like to use it in. I wish it was out right now.
The Adapteva story is quite amazing.
Andreas Olofsson designed the floating point part of the Analog Devices Blackfin, or whatever it was called. After some millions of dollars spent on that design he was, to quote Andreas, "ticked off" that only one percent of the chip was doing the actual floating point work. It was supposed to be a DSP after all.
So he set out, on his own, designing a chip to do what he wanted the way he wants. On a very low budget.
Much like our Chip really.
I'm really happy there are such crazy people in the world.
It's not a question of if it will run on batteries or not. It's a question of how big the batteries would need to be.
Boeing once developed an airborne laser system that could shoot down missiles in the 'boost phase', whatever that means. The laser wasn't much bigger than a refrigerator but it was mounted in a 747. Why a 747? Because the whole aircraft was filled with batteries to power the laser!
Sandy
Batteries small enough that a notepad size battery can power it for 12 hours ;-)
Set the bar high, ask for the impossible! Never know, we might get it.
Your 64 bit floating point, JavaScript agenda....
Not too sure that I need to go there with a Propeller. I already have a 64bit Quad Intel machine loaded with Debian.
Floating point has and will always be a human interface conversion. It creates delays in control just to present the result to a person.
And JavaScript - an object-oriented computer programming language commonly used to create interactive effects within web browsers.
Seems to mention that OOP quagmire and intended for web browsers.
+++++++++++
Neither is the vision of higher performing micro-controllers that I desire. Sorry, different strokes for different folks. There are plenty of SoC chips that can support these things.
As it happens the Espruino JS interpreter is now using 32 bit floats. Makes things a bit quicker on STM32 F4 ARM chips that only have 32 bit floating point units. Not sure how badly that breaks standards compliant code yet. For example I should be able to use numbers in JS like integers up to 53 bits, that is not going to work with the 32 bit float representation. Not at all. Most of the worlds scientific computing uses floating point. Super computers are designed for maximum FLOPS. Why? because you need the number range and all modern processors have fast floating point units. No. I think you will find that for many years now floating point calculation on modern processors is as fast as integer operations.
Javascript is course not designed for high speed computing but rather for simplicity for the programmer. A programming language needs to deal with numbers. Languages like C offer a huge variety of number types. JS throws away all that language complexity and only has floats. As they are 64 bit floats they can be used for 53 bit integers as well. That covers pretty much anything you want to do.
Modern JS also allows for arrays of other number types for those times you need to interface with real hardware, like graphic processors or audio systems. JS is not an object oriented language. At least not in the sense of C++, Java and the like. It has no concept of "class".
JS is a lot more sophisticated than Java or C++ in many ways. JS is based on "prototypes" which can be used in a C++/Java like way if you want but are far more flexible. JS has first class functions, lambdas and closures. Features that C++ and Java are only recently catching up with although they will never be able to express them so elegantly.
As for " interactive effects within web browsers", that has been true for decades but JS is now used extensively in server side software, in Qt based applications, in games, all over the place. And now on micro-controllers. I agree about the OOP quagmire, did I mention that JS is not object oriented. Sort of true. Netscape created JS as a way to easily do things on the WEB when they saw what a pile of Smile Java and it's applets was. Netscape also had server side JS at that time. It did not catch on for whatever reasons. The idea here is not about all out performance. Like Spin or BASIC or Forth it's not about raw speed it's about an easy to learn and use language for "normal" people. Yes indeed. Yep. And the Propeller 2 will be one of them if I can get it to work
I've seen Javascript that I'll never understand, and Javascript that is very clearly written.
It may not be object oriented in the strictest sense of the phrase, but it can be used in simple object oriented ways.
The next application I write will be in Javascript. I'm tired of making multi-os packages.
Nobody wants to do that anymore. I couple of years back I made an animated visulization of real-time data using Qt. Everybody was really enthusiastic about it until it came to the point that I had to explain to the boss how to download and install it on his Windows laptop. It was dead at that moment.
Later I made a JS version of the same thing for the browser. Even though it lacked many features of the original it was a hit everywhere.
My coworker had created a 3D visualization of the same real-time data using OpenGL. Same story. Now we have that in the browser using webgl. No problem.
Java was supposed to be the "write once, run anywhere solution" but the less said about that the better.
Anyway, you can always write the guts of you application in C++ if you crave type safety and all that. Emscripten will do the rest:)
Indeed.
I remember the early Mozilla demos, thinking that was going to hit big and cross-platform all kinds of stuff. Well, it's going to, and I'm personally stoked about it. Right now, I'm testing a big kind of application that makes heavy use of JS. Runs on pretty much anything, and it's going to change a niche solid in about a year when it opens to everyone.
IMHO, the big reason Netscape's work didn't catch on was due to Microsoft beating them up, and SUN working toward a similar end, but with a very different approach. And I can't stand Java. Really. I've put more time into dealing with Java issues than I care to admit, and as a result, I've never even once thought about writing a single line of it.
Had that time gone just a bit differently, we would be running a ton of stuff on whatever computer we can find, but it didn't. Fortunately, the vision didn't die, and it just took time.
I will end up writing some JS though. The thing I like the most is that it's a bit wild. One can write clean code, or something amazing that will defy reason.
Seems that Sun and Netscape had some deal going on together to bring programmability to the WEB. That is to say, Java Applets. Luckily Netscape realized the errors of that way and created JS as well.
Netscape and hence it's server side JS was doomed when MS gave IE out or free.
Java lived on to annoy us for ever in the server space. Where MS was not king.
JS lived on thanks to MS reverse engineering it so faithfully, warts and all, for Internet Explorer. Strange to think that even I have one thing to thank MS for doing !
Shame that MS fought hard to keep all the JS warts that Netscape wanted to remove when it came time to standardize the language at ECMA: You mean like this, runs in your browser or under node.js:
Here is the working sample of it by Linus Akesson:
Cut and paste it between some script tags in an HTML page and tell us what it says on the JS console in the browser. Or run it under node.
bf is cool. So is the whitespace language.