...On the other hand, 80 times faster is unfair as well. I'm sure the PASM version is pretty well optimized for the architecture ... I doubt you did much if any optimization of the Spin code with attention to actual execution speed of the compiled code.
Interesting. The Spin and PASM versions have the same loops and the same operations. I can't see what I could do with the Spin version to optimize it.
Except that in Spin it will be using 32 bit multiplies where as in PASM I'm only dealing with 13 bit * 13 bit and Lonesocks multiply bails out when it has exhausted all the bits actually set in the smallest operand. I can't imagine that accounts for the factor of 4 we are looking for.
Perhaps you could find a minute to cast an eye over it and make suggestions. Not that it's worth spending time on speeding up a Spin FFT.
On the other hand, "professional" grade features like conditional compilation and macros are (or should be) completely optional to use, yet enable some very sophisticated system design that's impossible to do otherwise (unless you add an external macro processor). That's the reason why I and others have been asking for a long time for hooks in the Propeller Tool for some kind of optional preprocessing phase for the compiler. Something like M4 would work, but anything else could be substituted. BST now handles PropBasic in that fashion.
You could just pass the code through m4 manually, then invoke the Propeller Tool. I've done that in the past when I've needed macros for the Atmel AVR assembler.
Maybe the chips are more expensive than those of a competitor. But a product's total cost involves more than the cost of the chips themselves. I would content that, with the Propeller, it's quicker to develop a product than with the less expensive competition, and that yields overall cost savings. One might argue that, with product volumes in the millions, say, you reach a point of diminishing returns on rapid application development (RAD) savings. I would counter that, when getting there first in a rapidly-changing marketplace means making it or not, RAD benefits may still trump raw component cost.
I agree any such professional grade features should be optional.
But I do worry that, well, imagine all such features were part of Spin from the get go. For sure all the Propeller heads writing code for OBEX would have used those features in clever ways. It's in their nature. The code in OBEX and other places would now be impenetrable to the beginner/casual programmer. The whole purpose in life of Spin, to be light weight and simple for beginners like BASIC, would have been negated.
So I worry that growing Spin in that way now could have negative consequences of the neophytes, a real part of the Parallax market now, whilst still not satisfying our hypothetical "professional".
1. Parallax has an established reputation as an educational/enthusiast niche. Attempting to move from that persona to a commercial one is going to be difficult to say the least.
as long as memory or a quick google of Parallax comes up with Basic Stamp, or the Hydra, I think it will be difficult for the average professional to give Parallax the time of day. I think this is where you need a real Business Development expert to give insight.
telling someone that there are 3 possible versions of C available is possibly more trepidatious than not
a smart person would likely look at potential risk to themselves, their career/standing at their company.
I think that a name change would be useful. Change to something like Gracey Technologies or whatever. Make Parallax a subsidiary of that new entity. Don't call the new chip the Propeller2... think of something else. All us old prop1 geeks will know it's really the prop2 but there is no need to scare off anybody by linking the new chip from a 'new' company to the old one that was big in BASIC Stamps. And for goodness sake don't put the image of a propeller beanie or similar on the new chip...just put some geeky looking code like GT-A8CP .... you get the idea. Make sure a more pro quality IDE is available for the new chip and make sure it has an integrated C compiler in it! It should be able to generate asm code to create peripherals easily, that will make the lack of built-in peripherals less of a drawback.
Parallax is a great company and I really do like the prop. I hope that they make lots of money with the new prop2 and that someday there will be a 3rd chip in the series :-)
Licensing ARM and making a multi-core ARM is not a bad idea either.
@Heater: Well reasoned. That dilemma has bounced around in my mind ever since the "it needs to be pro" discussion has been going on.
Maybe split the middle, and provide only a clean conditional code scheme? I think that one isn't beyond the goal of SPIN being accessible to pretty much anybody.
It seems to me, the coming new entity that will serve to introduce and support propellers for professionals could also take a different path, ignoring SPIN entirely. We have pretty effective C now, and we have some memory models, and lots of other tools, including binary drivers and such. A lot of the boot-strapping needed to make higher level use of the chip is done. Now that it is done, packaging that and formatting it for the professional makes perfect sense!
I still maintain that pro class tools really were not possible at release, because many of the ideas needed to realize them properly were not understood at that time. Now they are much farther along, with some best practice info, needed by professionals, in place now too.
Maybe don't do anything much to spin, maybe add conditionals, and that's it, minus whatever new functionality is needed for the larger memory space in the Prop II.
The more I think about this, the less I believe in the unification of the two directions.
So then, we see Parallax educational and Hobby, and Parallax Pro, each with very different models for supporting the same product.
One very nice thing about that is hobby / amateur / student types have a nice growth path into bigger and better things, while at the same time, not being forced into doing that.
Parallax has been down that path and has gotten burned badly, hence the effort to create their own chip from scratch. Parallax based the heart of their business on Scenix's SX processors. When Scenix got sued by Microchip and lost, it put a permanent hold on any future development of the SX. Fortunately for Parallax, the terms of the settlement allowed Scenix to continue to manufacture their existing designs. At one point, Scenix decided to no longer sell SXs except in wafer form (because Parallax wanted to buy them) and, finally, Scenix decided to stop even making wafers for this now obsolete design.
My main quibble with Spin and PASM (which I've stated elsewhere ad nauseum) is the lack of professional-level programming features, such as macros, conditional compiling, etc. These missing features represent the "big boy pants" that the Prop's dev tools have to grow into before it will be taken seriously in the commercial/industrial arena.
-Phil
Exactly right Phil!
If Prop2 comes riding in with a really pro looking IDE that has C built in and a nice macro assembler with the ability to generate PASM code
for peripherals it will sell much better. It should be able to generate code that can put multiple peripherals into a single cog using a tiny RTOS. Let professionals work with C and a PASM generator at first and then they might slowly begin to pick
up PASM and SPIN as they work on projects.
It should be able to generate asm code to create peripherals easily, that will make the lack of built-in peripherals less of a drawback.
Is something I and others have been thinking about for a long while. As it stands if you stumble across the Prop you might immediately move on as it is not made obvious that whilst it has no built in peripherals it is very easy to make them in software or easier still to just snag existing ones. I know this to be true because I did it myself.
Now the same is true of FPGA's, out of the box they are useless unless you spend a lot of time creating your own IP blocks. But wait FPGA vendors make a big deal about all the IP blocks you can get for SPI, UARTS, on board CPUs etc. They integrate these logic functions into their design tools to make it easy just to drop them ito your product.
Conclusion, any half page summary of the Prop in a brochure, data sheet or catalogue should contain a list of all the most important/common peripheral objects that are available for use with it. There should be block diagrams as examples of what is possible.
I'm not sure making it easier to generate such objects is possible but having them all ready to go in the IDE is essential along with some nice install wizards that configure pins, baud rates etc and drop them into your projects would be great. Just like they have for logic blocks in FPGA dev tools.
I'm not sure making it easier to generate such objects is possible but having them all ready to go in the IDE is essential along with some nice install wizards that configure pins, baud rates etc and drop them into your projects would be great. Just like they have for logic blocks in FPGA dev tools.
Parallax has been down that path and has gotten burned badly, hence the effort to create their own chip from scratch.
Yes, that's a sad story, but I really don't think they would be burned in that kind of a way by licensing ARM.
There are just so many ways ARM could be combined with copies of itself or along with other designs on one wafer.
Several cores able to run copies of Linux would be great fun! :-)
Just taking an ARM and a prop2 and encapsulating them together inside a single package
of some sort could be useful....this could be done by some of the really smart guys here on
the forum and bring them lots of $$$$ ... I bet you could do it Mike :-)
A powerful ARM, a prop2, a 4gb micro SD all inside a small package with Linux loaded in
the ARM...think of the awesome possibilities. having it all packaged together would make
it so much easier to add to a project....and don't forget to add optical I/O to the thing.
hmmm... ethernet, 1080p HDMI, great audio, multiple hi precision timers...etc
All that can be done with an ARM core on an FPGA, which have been available for some time.
I really do need to get comfortable with FPGA.
I bought a book but it was a really sad read so I learned little from it.
Now I'm stuck doing something other than tech work for about a year
so I have no daily contact with anyone that could help me in a hands-on
way with FPGA. :-(
I found it linked on Dangerous Prototypes. It's built on some MIT specific lab materials, but still pretty accessible. I've looked through the first portion and found answers to a lot of basic things I wondered about logic, gates and just foundation material I've not had exposure to before.
I really do need to get comfortable with FPGA.
I bought a book but it was a really sad read so I learned little from it.
Now I'm stuck doing something other than tech work for about a year
so I have no daily contact with anyone that could help me in a hands-on
way with FPGA. :-(
Just get one of the low-cost kits that are available. Here is a new one that will be available in a couple of weeks for $89:
That looks and sounds like some very impressive work! However, I see it is pretty much all written in assembly. Can multi-threading within one cog be accomplished in Spin?
Bruce
Peter's technique is terrific for PASM, but is not translatable into SPIN - as Mike pointed out, SPIN is interpreted, and the SPIN interpreter already occupies the whole cog - and even so it ends up executing only about 1/20th of PASM speed (that must be an average figure BTW - my experience is that SPIN is much slower than that in many cases).
However, a similar technique can be used in compiled languages. For example C can be compiled down to native PASM instructions which are then executed in a tight one-instruction overlay loop (this is the technique discovered by Bill Henning and generally called LMM). The basic LMM loop can be implemented in just a few instructions, leaving heaps of space in the same cog to do other things - such as supporting multithreading - or to implement support functions that would be inefficient to implement using in-line PASM instructions (e.g. stack manipulation, which takes several instructions to implement each time since the Propeller has no indexed addressing).
This is the approach Catalina takes. The various Catalina kernels not only all include the basic LMM loop, but also include various additional functions not found in either SPIN or PASM - e.g. floating point support, multithreading support, cog-to-cog function calls, external memory access etc, etc.
The result is a high-level language that can execute equivalent chunks of code at around 1/4 PASM speeds (i.e. 4 times slower, not four times faster!). It's actually quite difficult to compare the speed of complete C programs to complete PASM programs since it is impossible to have complete PASM program larger than 496 longs - but you can compare the execution speed of various chunks of code.
Or, looked at it another way, C executes between 5 and 10 times faster than SPIN - and adds floating point or multithreading support into the bargain!
Ross.
P.S. Note that there are several projects underway to both reduce the size of the SPIN interpreter and also add the capability to extend it via LMM - but to make enough space to implement multithreading in SPIN is a long way off - and the results would still execute only at SPIN speeds (possibly even slower).
Thank you leon for the link to the low-cost kit...that looks useful.
@RossH
Catalina is great!
I'm still amazed that it was your first attempt at writing a compiler.
IMO Parallax should add Catalina to their IDE as the supported C
compiler. (and kick in a bit of $ to keep you improving it) :-)
@RossH
Catalina is great!
I'm still amazed that it was your first attempt at writing a compiler.
IMO Parallax should add Catalina to their IDE as the supported C
compiler. (and kick in a bit of $ to keep you improving it) :-)
Hi Holly,
Naturally, I agree with you 110%
However, in fairness Catalina is not my first compiler, just my first C compiler - I wrote a compiler 30 years ago when I first worked as an embedded software engineer. That compiler implemented a language similar to Pascal but with real-time extensions. So I was already familiar with much of the basic compiler construction techniques. And in any case, with Catalina much of the work had already been done by the original authors of LCC.
Of course, one isn't restricted to a single processor on an FPGA and multi-core systems are quite easy to implement. Given that the ARM M1 core can run at 200 MIPS on a Virtex-4, there are some interesting possibilities, given that current FPGAs are a lot faster and larger.
Of course ... multi-core systems are quite easy to implement.
Aha! It must be Chip himself that is holding up the Prop II - maybe we can convince him to hand over the design to Leon to complete and retire to his nut farm.
Heater: I think you have hit on it - Free MIT licensed IP Peripherals
To comment on a number of points raised...
Mike G is right-on in that we need a macro expansion, include and ifdef. We have the latter two in homespun (does bst do include yet?). We should ask Michael & Brad to do it, with some help. For me, it's not a problem that the compilers are not Parallax - the important part is they are free to use and their basics have been proven sufficiently.
Pasm is extremely simple to grasp compared to most micros asm. And many magnitudes simpler than FPGA !!! It is mostly only required for implementing a set of peripherals (the IP) and the most frequently used cores are done. So, if you require a special IP core, take the time to learn pasm. The "Gold" series will drastically improve this, which will be fantastic. Don't forget that we only need 1 chip in the family (I keep repeating myself here as it is a MAJOR point) - well, I wish for a Prop 1B too
Do not underestimate the props lack of peripherals and cogs. There are lots of tweeks that can place multiple peripherals in a single cog. Mostly, these have not been required yet, so they haven't been done. Also, we do not have enough info about the counter/video hardware still - I am absolutely certain we have only touched the surface of what can be done here.
Spin is too slow for many things but not necessarily the main program(s). IIRC it takes spin 27+++ instructions to decode a bytecode - I reduced this significantly in my interpreter by using a 256 long vector table in hub. C takes a middle road, but uses more hub space. This is a mandatory requirement for the professionals (even tho spin does a reasonably good job, this is not what most professional engineers are looking for - and BTW I am not a C fan/user) !!!
Just to repeat a statement many of us have made often - Parallax should support homespun, bst, Catalina, ICC and Hannos debugger (with $ too).
While we don't always think Parallax are listening, I am certain they are - but they have many things to do... We are seeing results - maybe slower than we all would like, but remember, they are a small company and we do not want them to overstretch themselves either.
For the record... I do not see a licensed arm with a prop on a chip. Better, if you want an arm, add that to a prop (or vica versa). The prop is not a fully fledged micro-computer... it is a microcontroller with 8 cores. The iPad/NetBook/Phone market will be dominated with arms - I would never use a prop (propII) here, but as a peripheral chip, well maybe.
Lastly, I do not see the prop's cost as a deterrent. It can do a lot of jobs simpler than other micros, and when you compare the prop to a similar device with the peripheral set that the prop can do, there is no contest. How about you compare it to an FTDI chip that costs 50% of a prop (well maybe 40% when you add the xtal and eeprom). Man that FTDI chip is $$$.
Aha! It must be Chip himself that is holding up the Prop II - maybe we can convince him to hand over the design to Leon to complete and retire to his nut farm.
Ross.
I'd be surprised if portions of the Propeller II weren't implemented on an FPGA, as was done with the Propeller I. It's the logical way to design things like that, these days.
First of all you have 8 cogs to run not only cooperrative but also independent.
Implementing multi-threading in SPIN seems to be a lot of work.
Let's estimate you earn just 10 dollars per hour. How many hours of work will it be to write and test multi-threading SPIN?
And now calculate how many additional propeller-chips you can buy and add to your project to be able to do more than 8 things at the same time.
For really high-featured applications open up your mind and go buying a mini ITX-board (they start at $150 including RAM and a harddisc) to do all these super-rich featured things you dream of
buy using C++ or PC-RTOS or whatever you want.
Pasm is extremely simple to grasp compared to most micros asm. And many magnitudes simpler than FPGA !!!
VHDL and Verilog are *much* easier to use than PASM! And most MCUs are programmed in C, these days.
Lastly, I do not see the prop's cost as a deterrent. It can do a lot of jobs simpler than other micros, and when you compare the prop to a similar device with the peripheral set that the prop can do, there is no contest. How about you compare it to an FTDI chip that costs 50% of a prop (well maybe 40% when you add the xtal and eeprom). Man that FTDI chip is $$$.
USB is built-in to many MCUs like PICs, AVRs and ARMs. It doesn't add very much to the cost.
My special thanks to everyone that responded to the multi-threading in a single cog.
Holly, I am highly to inclined to agree with you to a certain extent on you previous viewpoint:
I think that a name change would be useful. Change to something like Gracey Technologies or whatever. Make Parallax a subsidiary of that new entity. Don't call the new chip the Propeller2... think of something else. All us old prop1 geeks will know it's really the prop2 but there is no need to scare off anybody by linking the new chip from a 'new' company to the old one that was big in BASIC Stamps. And for goodness sake don't put the image of a propeller beanie or similar on the new chip...just put some geeky looking code like GT-A8CP .... you get the idea.
However, I think the Propeller 2 is a fine name for chips to be sold at Parallax. As it was mentioned, Parallax is well known to the hobbiest market, and I think the name Parallax Semi-Conductor will meet up with some resistance to the commercial and industrial markets. I think a simple company name change and a different chip marking for the commercial and industrial markets might be well in order. I think that was a very good idea on your part, with some very good foresight.
Bruce
P.S. A little lipstick and a little rouge could provide a big payoff.
VHDL and Verilog are *much* easier to use than PASM!
This may be true in the world of specialist hardware designers - otherwise not. Many members of these forums can easily produce a working interface controller for something like an SPI or I2C peripheral in just a few dozen PASM instructions - and have done so! But the number of people in these forums who could do so in VHDL would closely approach zero.
VHDL (see here) is a large and complex language derived at least in part from Ada (possibly the most complex general-purpose language in common usage). On the other hand, PASM is so easy that many people learn to use it without even prior programming experience.
The synthesisable subset of VHDL that is used with FPGAs is relatively small, and using it is no harder than programming in C. Designing hardware requires a different mindset from programming a software application, of course, but all students completing an electrical engineering course these days will have had some FPGA design experience as a course requirement. Verilog is based on C, and many people find it easier to use than VHDL. I can't get on with Verilog, personally. Many hobbyists enjoy working with FPGAs.
Manufacturers like Xilinx and Altera make things easy by providing pre-written logic functions that can be configured to a user's requirements and dropped into a design, for things like SPI, UARTs and so on, right up to complete processors. It's something like using code in the Obex, but a lot easier.
There is a difference between easy to use and easy to learn to use.
Easy to use, for somebody experienced in the use of the tool, boils down to the effort associated with the use of the tool. Easy to learn to use, which is often just written "easy to use", is the effort required to gain the skill necessary to use the tool, and secondly, the effort required to improve the use of the tool, up to it's optimal scope of functionality.
I would imagine implementing lots of complex logic cases with VHDL is easier to do than it is in PASM, largely because VDHL is designed to address that use case. (and many others) That design comes at a cost in terms of barrier to entry, which from my experience looking things like VDHL over, is significantly higher than it is for PASM.
Comments
Interesting. The Spin and PASM versions have the same loops and the same operations. I can't see what I could do with the Spin version to optimize it.
Except that in Spin it will be using 32 bit multiplies where as in PASM I'm only dealing with 13 bit * 13 bit and Lonesocks multiply bails out when it has exhausted all the bits actually set in the smallest operand. I can't imagine that accounts for the factor of 4 we are looking for.
Perhaps you could find a minute to cast an eye over it and make suggestions. Not that it's worth spending time on speeding up a Spin FFT.
Hear hear!
-Phil
I agree any such professional grade features should be optional.
But I do worry that, well, imagine all such features were part of Spin from the get go. For sure all the Propeller heads writing code for OBEX would have used those features in clever ways. It's in their nature. The code in OBEX and other places would now be impenetrable to the beginner/casual programmer. The whole purpose in life of Spin, to be light weight and simple for beginners like BASIC, would have been negated.
So I worry that growing Spin in that way now could have negative consequences of the neophytes, a real part of the Parallax market now, whilst still not satisfying our hypothetical "professional".
I think that a name change would be useful. Change to something like Gracey Technologies or whatever. Make Parallax a subsidiary of that new entity. Don't call the new chip the Propeller2... think of something else. All us old prop1 geeks will know it's really the prop2 but there is no need to scare off anybody by linking the new chip from a 'new' company to the old one that was big in BASIC Stamps. And for goodness sake don't put the image of a propeller beanie or similar on the new chip...just put some geeky looking code like GT-A8CP .... you get the idea. Make sure a more pro quality IDE is available for the new chip and make sure it has an integrated C compiler in it! It should be able to generate asm code to create peripherals easily, that will make the lack of built-in peripherals less of a drawback.
Parallax is a great company and I really do like the prop. I hope that they make lots of money with the new prop2 and that someday there will be a 3rd chip in the series :-)
Licensing ARM and making a multi-core ARM is not a bad idea either.
Maybe split the middle, and provide only a clean conditional code scheme? I think that one isn't beyond the goal of SPIN being accessible to pretty much anybody.
It seems to me, the coming new entity that will serve to introduce and support propellers for professionals could also take a different path, ignoring SPIN entirely. We have pretty effective C now, and we have some memory models, and lots of other tools, including binary drivers and such. A lot of the boot-strapping needed to make higher level use of the chip is done. Now that it is done, packaging that and formatting it for the professional makes perfect sense!
I still maintain that pro class tools really were not possible at release, because many of the ideas needed to realize them properly were not understood at that time. Now they are much farther along, with some best practice info, needed by professionals, in place now too.
Maybe don't do anything much to spin, maybe add conditionals, and that's it, minus whatever new functionality is needed for the larger memory space in the Prop II.
The more I think about this, the less I believe in the unification of the two directions.
So then, we see Parallax educational and Hobby, and Parallax Pro, each with very different models for supporting the same product.
One very nice thing about that is hobby / amateur / student types have a nice growth path into bigger and better things, while at the same time, not being forced into doing that.
Parallax has been down that path and has gotten burned badly, hence the effort to create their own chip from scratch. Parallax based the heart of their business on Scenix's SX processors. When Scenix got sued by Microchip and lost, it put a permanent hold on any future development of the SX. Fortunately for Parallax, the terms of the settlement allowed Scenix to continue to manufacture their existing designs. At one point, Scenix decided to no longer sell SXs except in wafer form (because Parallax wanted to buy them) and, finally, Scenix decided to stop even making wafers for this now obsolete design.
Exactly right Phil!
If Prop2 comes riding in with a really pro looking IDE that has C built in and a nice macro assembler with the ability to generate PASM code
for peripherals it will sell much better. It should be able to generate code that can put multiple peripherals into a single cog using a tiny RTOS. Let professionals work with C and a PASM generator at first and then they might slowly begin to pick
up PASM and SPIN as they work on projects.
I agree whole heartedly with all that you said!
Is something I and others have been thinking about for a long while. As it stands if you stumble across the Prop you might immediately move on as it is not made obvious that whilst it has no built in peripherals it is very easy to make them in software or easier still to just snag existing ones. I know this to be true because I did it myself.
Now the same is true of FPGA's, out of the box they are useless unless you spend a lot of time creating your own IP blocks. But wait FPGA vendors make a big deal about all the IP blocks you can get for SPI, UARTS, on board CPUs etc. They integrate these logic functions into their design tools to make it easy just to drop them ito your product.
Conclusion, any half page summary of the Prop in a brochure, data sheet or catalogue should contain a list of all the most important/common peripheral objects that are available for use with it. There should be block diagrams as examples of what is possible.
I'm not sure making it easier to generate such objects is possible but having them all ready to go in the IDE is essential along with some nice install wizards that configure pins, baud rates etc and drop them into your projects would be great. Just like they have for logic blocks in FPGA dev tools.
This is something 12blocks does to some extent.
Yes, that's a sad story, but I really don't think they would be burned in that kind of a way by licensing ARM.
There are just so many ways ARM could be combined with copies of itself or along with other designs on one wafer.
Several cores able to run copies of Linux would be great fun! :-)
Just taking an ARM and a prop2 and encapsulating them together inside a single package
of some sort could be useful....this could be done by some of the really smart guys here on
the forum and bring them lots of $$$$ ... I bet you could do it Mike :-)
A powerful ARM, a prop2, a 4gb micro SD all inside a small package with Linux loaded in
the ARM...think of the awesome possibilities. having it all packaged together would make
it so much easier to add to a project....and don't forget to add optical I/O to the thing.
hmmm... ethernet, 1080p HDMI, great audio, multiple hi precision timers...etc
http://www.arm.com/products/processors/cortex-m/cortex-m1.php
I really do need to get comfortable with FPGA.
I bought a book but it was a really sad read so I learned little from it.
Now I'm stuck doing something other than tech work for about a year
so I have no daily contact with anyone that could help me in a hands-on
way with FPGA. :-(
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-111-introductory-digital-systems-laboratory-fall-2002/lecture-notes/
I found it linked on Dangerous Prototypes. It's built on some MIT specific lab materials, but still pretty accessible. I've looked through the first portion and found answers to a lot of basic things I wondered about logic, gates and just foundation material I've not had exposure to before.
Just get one of the low-cost kits that are available. Here is a new one that will be available in a couple of weeks for $89:
http://www.em.avnet.com/evk/home/0,4534,CID%253D62855%2526CCD%253DUSA%2526SID%253D32214%2526DID%253DDF2%2526LID%253D32232%2526BID%253DDF2%2526CTP%253DEVK,00.html?SUL=s6microboard
It uses the MicroBlaze processor, which has some advantages over some of the ARM cores in that it has hardware floating-point operations.
Peter's technique is terrific for PASM, but is not translatable into SPIN - as Mike pointed out, SPIN is interpreted, and the SPIN interpreter already occupies the whole cog - and even so it ends up executing only about 1/20th of PASM speed (that must be an average figure BTW - my experience is that SPIN is much slower than that in many cases).
However, a similar technique can be used in compiled languages. For example C can be compiled down to native PASM instructions which are then executed in a tight one-instruction overlay loop (this is the technique discovered by Bill Henning and generally called LMM). The basic LMM loop can be implemented in just a few instructions, leaving heaps of space in the same cog to do other things - such as supporting multithreading - or to implement support functions that would be inefficient to implement using in-line PASM instructions (e.g. stack manipulation, which takes several instructions to implement each time since the Propeller has no indexed addressing).
This is the approach Catalina takes. The various Catalina kernels not only all include the basic LMM loop, but also include various additional functions not found in either SPIN or PASM - e.g. floating point support, multithreading support, cog-to-cog function calls, external memory access etc, etc.
The result is a high-level language that can execute equivalent chunks of code at around 1/4 PASM speeds (i.e. 4 times slower, not four times faster!). It's actually quite difficult to compare the speed of complete C programs to complete PASM programs since it is impossible to have complete PASM program larger than 496 longs - but you can compare the execution speed of various chunks of code.
Or, looked at it another way, C executes between 5 and 10 times faster than SPIN - and adds floating point or multithreading support into the bargain!
Ross.
P.S. Note that there are several projects underway to both reduce the size of the SPIN interpreter and also add the capability to extend it via LMM - but to make enough space to implement multithreading in SPIN is a long way off - and the results would still execute only at SPIN speeds (possibly even slower).
Thank you leon for the link to the low-cost kit...that looks useful.
@RossH
Catalina is great!
I'm still amazed that it was your first attempt at writing a compiler.
IMO Parallax should add Catalina to their IDE as the supported C
compiler. (and kick in a bit of $ to keep you improving it) :-)
Hi Holly,
Naturally, I agree with you 110%
However, in fairness Catalina is not my first compiler, just my first C compiler - I wrote a compiler 30 years ago when I first worked as an embedded software engineer. That compiler implemented a language similar to Pascal but with real-time extensions. So I was already familiar with much of the basic compiler construction techniques. And in any case, with Catalina much of the work had already been done by the original authors of LCC.
Ross.
Aha! It must be Chip himself that is holding up the Prop II - maybe we can convince him to hand over the design to Leon to complete and retire to his nut farm.
Ross.
Heater: I think you have hit on it - Free MIT licensed IP Peripherals
To comment on a number of points raised...
Mike G is right-on in that we need a macro expansion, include and ifdef. We have the latter two in homespun (does bst do include yet?). We should ask Michael & Brad to do it, with some help. For me, it's not a problem that the compilers are not Parallax - the important part is they are free to use and their basics have been proven sufficiently.
Pasm is extremely simple to grasp compared to most micros asm. And many magnitudes simpler than FPGA !!! It is mostly only required for implementing a set of peripherals (the IP) and the most frequently used cores are done. So, if you require a special IP core, take the time to learn pasm. The "Gold" series will drastically improve this, which will be fantastic. Don't forget that we only need 1 chip in the family (I keep repeating myself here as it is a MAJOR point) - well, I wish for a Prop 1B too
Do not underestimate the props lack of peripherals and cogs. There are lots of tweeks that can place multiple peripherals in a single cog. Mostly, these have not been required yet, so they haven't been done. Also, we do not have enough info about the counter/video hardware still - I am absolutely certain we have only touched the surface of what can be done here.
Spin is too slow for many things but not necessarily the main program(s). IIRC it takes spin 27+++ instructions to decode a bytecode - I reduced this significantly in my interpreter by using a 256 long vector table in hub. C takes a middle road, but uses more hub space. This is a mandatory requirement for the professionals (even tho spin does a reasonably good job, this is not what most professional engineers are looking for - and BTW I am not a C fan/user) !!!
Just to repeat a statement many of us have made often - Parallax should support homespun, bst, Catalina, ICC and Hannos debugger (with $ too).
While we don't always think Parallax are listening, I am certain they are - but they have many things to do... We are seeing results - maybe slower than we all would like, but remember, they are a small company and we do not want them to overstretch themselves either.
For the record... I do not see a licensed arm with a prop on a chip. Better, if you want an arm, add that to a prop (or vica versa). The prop is not a fully fledged micro-computer... it is a microcontroller with 8 cores. The iPad/NetBook/Phone market will be dominated with arms - I would never use a prop (propII) here, but as a peripheral chip, well maybe.
Lastly, I do not see the prop's cost as a deterrent. It can do a lot of jobs simpler than other micros, and when you compare the prop to a similar device with the peripheral set that the prop can do, there is no contest. How about you compare it to an FTDI chip that costs 50% of a prop (well maybe 40% when you add the xtal and eeprom). Man that FTDI chip is $$$.
I'd be surprised if portions of the Propeller II weren't implemented on an FPGA, as was done with the Propeller I. It's the logical way to design things like that, these days.
First of all you have 8 cogs to run not only cooperrative but also independent.
Implementing multi-threading in SPIN seems to be a lot of work.
Let's estimate you earn just 10 dollars per hour. How many hours of work will it be to write and test multi-threading SPIN?
And now calculate how many additional propeller-chips you can buy and add to your project to be able to do more than 8 things at the same time.
For really high-featured applications open up your mind and go buying a mini ITX-board (they start at $150 including RAM and a harddisc) to do all these super-rich featured things you dream of
buy using C++ or PC-RTOS or whatever you want.
best regards
Stefan
VHDL and Verilog are *much* easier to use than PASM! And most MCUs are programmed in C, these days.
USB is built-in to many MCUs like PICs, AVRs and ARMs. It doesn't add very much to the cost.
Holly, I am highly to inclined to agree with you to a certain extent on you previous viewpoint:
However, I think the Propeller 2 is a fine name for chips to be sold at Parallax. As it was mentioned, Parallax is well known to the hobbiest market, and I think the name Parallax Semi-Conductor will meet up with some resistance to the commercial and industrial markets. I think a simple company name change and a different chip marking for the commercial and industrial markets might be well in order. I think that was a very good idea on your part, with some very good foresight.
Bruce
P.S. A little lipstick and a little rouge could provide a big payoff.
This may be true in the world of specialist hardware designers - otherwise not. Many members of these forums can easily produce a working interface controller for something like an SPI or I2C peripheral in just a few dozen PASM instructions - and have done so! But the number of people in these forums who could do so in VHDL would closely approach zero.
VHDL (see here) is a large and complex language derived at least in part from Ada (possibly the most complex general-purpose language in common usage). On the other hand, PASM is so easy that many people learn to use it without even prior programming experience.
Ross.
Manufacturers like Xilinx and Altera make things easy by providing pre-written logic functions that can be configured to a user's requirements and dropped into a design, for things like SPI, UARTs and so on, right up to complete processors. It's something like using code in the Obex, but a lot easier.
Easy to use, for somebody experienced in the use of the tool, boils down to the effort associated with the use of the tool. Easy to learn to use, which is often just written "easy to use", is the effort required to gain the skill necessary to use the tool, and secondly, the effort required to improve the use of the tool, up to it's optimal scope of functionality.
I would imagine implementing lots of complex logic cases with VHDL is easier to do than it is in PASM, largely because VDHL is designed to address that use case. (and many others) That design comes at a cost in terms of barrier to entry, which from my experience looking things like VDHL over, is significantly higher than it is for PASM.