The propeller can only grow from here
SONIC the Hedgehog
Posts: 321
So to my understanding parallax introduced the world to the propeller in 2006. But what has been done with it? This chip is absolutely amazing! I praise the engineers and the brains behind this and the genius of a president who had the guts to set a new standard. If you compare it to the average CPU in a computer, it's not as fast not as powerful. Well, it may be small, but with eight cores at 20 MIPS, you could finish a program faster with much more precision then a tradition CPU. In fact mom spent some 560 dollars on a computer that had a four core CPU. I saw the eight core parallax propeller at fry's electronics for 12.99. I've heard of the new propeller 2 and I believe that it will be even more powerful and features look amazing. I think that parallax can't go wrong with this, but only get better, and raise the bar for other competitors in the microprocessor department. But what dos propeller two mean for propeller one? I say more opportunities. When Sega released the genesis, they chose the mc680000. So what does that have to do with this? Well, the predecessor to sega's genesis was the master system. So what. Well we know that the Z80 was at the heart of the master system, but wasn't enough to compete. So out comes genesis. The catch here is that the genesis also included the Z80. My point? Well, the propeller 2 spells good new for the propeller 1. Why? I believe that a whole new host of embedded systems can be created with complex, yet easily manageable architecture. I have strong belief the propeller would indeed survive as a micro computer system, using both versions of the propeller chip, making the overal system size manageable, and very easy to keep up with. The bottom line, I think the propeller chip deserves to be at the heart of a commercially available micro computer. The architecture removes the need for large, and very processor demanding programs and solutions with eight cores, providing the opportunity for a true, muiltitasking system!!!!
I have a dream to at least one day make a prototype of this system, and in all honesty, I don't care where it goes, I would just like to see this happen.
So, who agree and disagrees?
I have a dream to at least one day make a prototype of this system, and in all honesty, I don't care where it goes, I would just like to see this happen.
So, who agree and disagrees?
Comments
The chip is good otherwise.
Parallax will address this when they release the Prop II.
The design of the chip is beyond brilliant. It was the ability to generate video in software that sucked me into Propellerland, and not as in X--- land sorta kind yeah you can do it but it was an original design goal that influenced the whole instruction set. I've done some programming for the Atari 2600 Stella chipset, using a standard 6502 CPU and doing the video stuff in software, and it's a much bigger pain because the cycle counts for instructions vary. The Propeller was very obviously designed from the ground up to do video in software, and at a farily low clock rate compared to the video bit rate.
And putting in eight cores EACH of which can do video in software -- well where else do you find that for eight dollars?
Well, I guess I should disagree here on behalf of all the many tool builders in these forums
There have in fact been some amazing tools built for the Propeller (and before anyone thinks I am taking Kye's comment as a personal affront, I am excluding Catalina, which is after all a fairly pedestrian port of a fairly pedestrian C compiler - I am actually thinking of tools like Hanno's ViewPort and Brad's BST. PropForth is another one. And of course the various Basic compilers. Even Kye himself has contributed some really amazing OBEX components).
The trouble is that Parallax has not gotten behind any of these tools - the way other chip manufacturers do as a matter of course. In fact Parallax still doesn't seem to see the connection between good software tools and increased chip sales. Parallax Semiconductor appears to be a bust so far, and the rate of release of the "gold standard" OBEX components is glacial to say the least. And also (to saddle up my own latest hobbyhorse for a minute) none of these "gold standard" OBEX components are any use at all from the plethora of other languages now available on the Propeller - because there is no standard for how such components should be integrated and used!
No wonder that the general consensus of opinion about the Propeller chip seems to be that "the chip is good" but no-one in the commercial or industrial sphere actually uses it for much (I'm excluding us dedicated fans here in the forums of course - I doubt if our combined chip purchases will keep the wolf from Parallax's door).
Parallax had to have their head battered against the wall repeatedly about the absolute necessity of a C compiler, and here we are 5 years after the Prop 1 was first released with (1) a discontinued and unsupported commercial C compiler, (2) a home-brewed C compiler built by a fan; and (3) a very immature alpha port of GCC!
After five years! The next generation of the Propeller is nearing release, and the first one has never reached its full potential because of a lack of understanding that software is just as important to a chip's success as hardware!
Ross.
I disagree that the Spin language will propel the Propeller. I think Spin has held the Propeller back from being more widely accepted. I have studied the Spin language in detail, and have written a simulator that executes Spin bytecodes. However, I am hesitant to do a lot of programming in Spin because it is a proprietary language. Any effort I put into writing Spin code cannot be used on other processors or run on a PC, Mac or Linux system. This is part of the reason I wrote spinsim, so I could run Spin code on a PC.
Spin has some nice features for beginners, but it also contains a lot of features that are confusing to beginners, and even some experienced programmers. In retrospect, I think it would have been much better to have released the Prop with a PBasic language for beginning programmers and programmers that wanted to upgrade from the Stamp to the Prop. Some of the features of Spin are too complicated for a lot of people that only know how to program the Stamp.
If Parallax wanted a more advanced language for the Prop at the beginning they should have used a subset of the C++ syntax for Spin. This would make it a lot easier for Spin programmers to transition to C/C++, which is a more advanced and widely accepted language. Spin is close to being a subset of C++, but the slight differences in syntax causes problems.
PropGCC will provide the path for growth for the Prop, and the Prop 2 will get a lot of attention from developers who are currently using other solutions.
Dave
The belief that only Spin can bring out the multiprocessing abilities of the Prop is incorrect. Almost any language can support functions that do cognew, coginit, lockset, etc. GCC is able to convert these directly into assembly instructions.
One advantage of Spin is it's VM that executes bytecodes that are very compact. However, it would have been possible to develop a register-based VM instead of a stack-based VM that would work well with C/C++ and would also use compact bytecodes. In fact, this is how the ZOG C/C++ compiler works.
C++ has many pieces and some of them are very very expensive in terms of resources used, both memory and speed. That's why there really aren't any full C++ implementations used for microcontrollers. You'll see some partial implementations like for the Arduino.
BTW, I looked at the details of ZOG and it looks like its VM is also stack-based. I was wrong in thinking that it used registers.
Yep, Prop users have been so desperate for tools that they come up with things
like, building a Z80 emulation so they can run CP/M on the Prop and hence the
first C compiler to run on a Prop, BDS C. Or the byte code interpreting system
Zog so as to be able to use a real GCC C/C++ compiler. Then there are all the BASIC
Forth and other systems that have grown up.
What happened in recent years is the massive interest in "open source". Both
open source software, starting with compilers and open source hardware designs.
A lot of the success of the Arduino can be put down to it's open source roots.
You might say that the average user does not care about how open source his
compiler is, but those who want to contribute to a "community" of like
minded users are seriously put off by proprietary systems and hence a lot
of good developers have their fun elsewhere.
Parallax has been very slow to to realize and/or embrace this open source
phenomena. Luckily they are now fully behind it with the sponsoring of the GCC
tool chain and a total rewrite of the Spin compiler as an open source tool in
the near future.
propgcc may still be in beta but I don't think "very immature" is fair. It has
handled everything I have thrown at it and performed optimizations I would
never have imagined. "C code compiled to run in a COG", your kidding me right?
As ever, C++ is a perfectly fine language for micro-controllers. Stay away from memory and time eating features and it performs as well as C code written to do the same job. In fact it can generate identical code as object oriented code written in C. You only take a hit in C++ overheads if you are doing things that would give you those overheads in C as well.
I know micro-controller C++ implementations may come with out all the big time standard library features but language wise the Arduino C++ is no "subset".
Also I was just typing this:
Sonic,
No, C++ does not need to be modified to use it with the Prop. My Zog system runs
C++ code on the Prop no problem. Compiled to byte codes and interpreted. A lot
like the Spin system really.
The up and coming GCC compiler for the Prop also compiles normal C++ to Prop
assembler, both real native assembler and LMM executed assembler. Very
impressive it is to.
Boosting the ROM to megabytes helps nothing as the RAM from which code is run
is only 32K and 196K in Prop II (I think). Also remember that executing Prop
instructions from RAM is at least 4 times slower than running from COG. The Prop
is a very special micro-controller and will not make a nice general purpose CPU
compared to those that are designed to be that.
Any talk of putting WinCE on the Prop will get you onto by ignore list:)
You can do a google search for "site:forums.parallax.com zog" and I'm sure you
will find it. I have not done much work on it for a while as there is so much
going on around here. Be aware that Zog is not a compiler it is just a simple
byte code interpreter for the instructions of the ZPU processor for which there
is a GCC taget.
As mentioned there is plenty of software support both buried in these forums as well as the obex. User contributed software is a two-edged sword. While it takes burden of the company to produce, it also adds the potential of complication if something should go wrong with the code in a mission critical operation if Parallax promotes it officially (Gold Standard). Careful care is required here. The only fault I've ever found in Parallax regarding new code is their speed to adopt new developments. (It was more than two years from the release of fsrw to when we saw any official products which used the SD card.) That being said, big companies can't turn on a dime.
If I wanted am ARM (or some other stronger processor) which could handle C, and run linux where would the fun be in that? I'd just use it to run BST and go back to programming my Propeller.
OBC
Excellent:)
Yes, in fact there is project underway to translate Spin source code into C++. Spin objects become simple C++ classes.
Starting other cogs from C or C++ is the same, both Catalina and GCC have builtin functions for COGNEW and all the other special Prop features.
But to heater, the only time I'd ever put any windows on the prop would be for Dreamcast. BAM!