Next Generation SPIN
jazzed
Posts: 11,803
There are some blaringly obvious missing features in the otherwise well done spin language. Asking Parallax to add features to current SPIN is probably an exercise in futility, or minimally an invitation of·derisive flames from forum fan-boys; still I must do this because I like the product and would like to see if there is a chance that feature omissions might be corrected so that I can feel free to become deeply entrenched and continue being repeat product buying customer rather than seeking alternatives.
A next generation SPIN and·Propeller ROM·might address the problems enumerated below.
A third party tool might be able to solve some issues in a nicely integrated way ... maybe some of the list has been addressed in recent developments. Many issues have been hashed over and over. Some issues could be addressed in tool "preferences", others require major hacking in the spin interpreter.
Anyway, here is the list of basic enhancements I would like to see by priority:
Any development organization has to draw a "water-line" for projects and features. If a good priority list can be presented from users, maybe there is a chance that something could be done.
There are other issues I'm sure that should be welcomed in open public discourse.
If there acceptable solutions available for any of these, please speak-up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
A next generation SPIN and·Propeller ROM·might address the problems enumerated below.
A third party tool might be able to solve some issues in a nicely integrated way ... maybe some of the list has been addressed in recent developments. Many issues have been hashed over and over. Some issues could be addressed in tool "preferences", others require major hacking in the spin interpreter.
Anyway, here is the list of basic enhancements I would like to see by priority:
- The ability to pass·an object pointer to another with full syntactic access of the passed object's public elements by the receiving object.
- Integrated object inheritance.
- The formal ability to use C-like·method pointers rather than obj hacks.
- Fully integrated IDE C-like preprocessor #defines and conditionals.
- Fully integrated IDE preprocessor #include statement for any valid code or #defines.
- The ability to specify a path for includes and library·objects.
- Device download speed/protocol error recovery for interfaces other than USB/COM port.
- The ability to selectively define VAR variables as public.
- The ability to create C-like VAR data-structures.
- A form·of·object polymorphism similar to Java abstract or interface classes.
- Pre-compile and post-compile tool command options for utilities (such as PhiPI's clean tool).
- ...
Any development organization has to draw a "water-line" for projects and features. If a good priority list can be presented from users, maybe there is a chance that something could be done.
There are other issues I'm sure that should be welcomed in open public discourse.
If there acceptable solutions available for any of these, please speak-up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Comments
You have to work from the bottom up — not from the top down. It's a lot harder but, in the end, more effective.
-Phil
(or maybe some addition to BST, when BradC hits the ground again.)
Phil's got the right idea for approach to this... [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Take a look at the C compiler - that was a complete ground up development with very little input from the parallax team.
Keep in mind that Parallax is first, and foremost, a hardware company. They make great hardware with millions, if not billions of usages, and they target them for the masses, not some guy with a PhD in electrical engineering who can visualize what the electrons are doing on a substrate (though there are a few of those on these boards as well
I think, for what you get and what you can do, the price of entry is exteremely low. A quick anecdote to illustrate my point - I spent 2 weeks writing code/troubleshooting/pulling hair out to get my pic 877 to talk to an eeprom device. I was up and talking to eeprom, lcd, servos, and an rs232 breakout board I had created before all in under 24 hours with the propeller. I think I'll sacrifice some of the neat C syntax for that kind of rapid development.
Another way to go is to port Small-Talk or Objective-C.
Just my 2 cents.
There are free versions of the Microchip C18, C30 and C32 compilers. They are adequate for most people.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Now, I will concur that the AVR circles definitely trump both microchip and parallax in terms of open development. I can create my own tool chain using gcc and I can write in c/c++/assembler or any compilable language that gcc supports. There is a huge amount of support in terms of platform libraries for AVR. There is a big difference between that and the pic compilers though - I have yet to see a single open source pic compiler (and was actually tempted to write one at one time until I found AVR).
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
SPIN should definitely not be C++ especially given the ways people abuse C++. Improvements can make SPIN more useful though. When folks are fully emersed in a language they find out about it's strengths and weaknesses. At some point you find yourself moving on to language 17 or language design number 4 or whatever.
Pointers are most new C programmers worst enemy and a good old friend otherwise unless you have to teach them [noparse]:)[/noparse] Stripping semantics from pointers leaves you with indirect addressing on one extreme and objects on another. Object references are nothing more than glorified encapsulated pointers.
I am not an enemy of the market approach. Evaluating what is available is part of the market decision. The Propeller is an interesting chip and SPIN offers a fair solution given the size of Propeller memory. It is a good starter and a refreshing aside for the experienced offering some room for growth. Some things about it drive me crazy; other things make me happy.
Thing is I don't personally have time or drive to create bottom up solutions; those who do have time or make money on it can consider opportunities for improvements. Having seen Brad's development, maybe he will consider some of the list items. I'm just interested in having tools for creating reasonably maintainable and growing products.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
I can change my version of the interpreter (ClusoInterpreter). I haven't touched it for over 3 months (just needs final debugging). I have room to implement extensions if they are valid and enough demand. There didn't seem to be enough interest for me to give it priority. I am expecting about a 20-30% speed improvement, but it will use 3KB of hub (2K for the code as the current Interpreter is in ROM) and 1KB for lookup tables.
Comments welcome
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
cruising][noparse][[/noparse]url=http://www.bluemagic.biz]cruising[noparse][[/noparse]/url][/url]
This is a [noparse][[/noparse]b]bold[noparse][[/noparse]/b] test.
Enter the propeller. In a few hours I had a working prototype using a 3axis accelerometer via a wii nunchuck controller, an lcd, a ping sensor, and two servos in a pan/tilt configuration (I tried hooking up a glcd to implement a radar display but failed in that attempt, still working on it). Next I put TV and video out and shocked my family. All in a span of two days.
To contrast, I did an experiment and spent a week and a half learning how to build a tool chain correctly for avr, getting my makefile just right, hooking it up with an IDE I wrote for BrickOS a while back (gcc based so it was a no brainer and took all of about 4 hours), and then fiddled with bits and ports and datasheets. It took me almost 2 weeks to get everything the same as the propeller but the audio/video out (show me an avr chip - on it's own that is dip based that can generate COLOR video out and have bandwidth for more, for that matter, show me a pic that is dip based that runs at the props speed and has the computational power of 8 parallel cores - that's like saying a 586 is better than a dual core just because its harder to code for it).
Again, first day I got my prop, looked at datasheet for circuit - super simple - bread boarded it in about 10 minutes (had all parts but the chip) and had all that I mentioned above.
The point being that whether Spin is true OO or not - and I was one who posted early on asking about if it was truly OO - it still definitely has rapid application development potential. I think you can truly say that the propeller chip is the RAD pioneer of hardware. Nowhere else can you have complete working solutions in hours. That saves time which always equals money. I think the commercial applications still haven't been truly realized yet as this chip is capable of obsoleting existing know solutions for problems. Think of it this way - if you have multiple design problems that you have to meet, using the propeller you might be able to meet those objectives with a single drop in chip and since it's firmware based, upgrades can be made in the field for changing requirements.
Post Edited (soshimo) : 1/6/2009 12:53:29 AM GMT
Welcome to Propeller. Most of us who spend any time with Prop have been through that first experience. It was indeed nice to get something running quickly. I spent a day last week getting an ARM to load and run a program ... haven't thought about video on it yet because I turned to Propeller first to test some video ideas and hardware interface for my project because I have more of that hardware than I need ... and ran into some of the same old limitations I had forgotten about. I'm about a third through the SPIN version of the product, I'll do the ICCPROP version for speed (hoping I don't run out of memory as always) then I'll go back to the ARM development. Meanwhile it occured to me that a tool that generates certain SPIN code would be useful and I might try to productize that ... who knows.
True OO down to overloads, copy constructors, etc... is not important to me, but the convenience that inheritance provides a very useful place to put common attributes that I am currently having to replicate in each of about 15 files ... mostly getters and setters ... big waste. Just having the ability to make some object data public or inherit the the getters/setters would remove that problem although it would be less "safe". I don't expect to really need encapsulation.
@cluso I'm interested in your ideas on having the ability to handle the spin-centric issues. Have you ever considered doing a SPIN VM for other CPUs? That would make SPIN more attractive for multiple sourcing CPUs. One of the big advantages of C is most CPUs have a tool-chain - another is performance of course. Java found some success in VMs, but it is really too fat to be practical in standard or chopped down embedded form. SPIN is a good compromise as long as typical development expectations are met that bring SPIN out of "toy mode".
@mpark. I'll look into your threads to see if I can find your object passing implementation. I know that one can use DAT instead of VAR data for sharing an object as long as the object is set in the user file. The problem comes when one needs to choose a different spin object and 15 files need to be changed to use a different device driver. Just using a dummy API is not good enough if I remember unless you go to the trouble of using Stevenmess' DOL approach which is not attractive longer term. A preprocessor would help there, but that's still a pain in the rear for feature/maintenance unless it can mitigate change.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
If you guys implement somthing in your independent tool chain and it blows up, it only impacts you and the few others that are using it, the same thing happens with the Tool and the consequences are dire. So implement it, show that it works, then show how it's indispesible in implementing a particular real world situation and not just another (older) way of skinning the same cat.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Post Edited (Paul Baker) : 1/6/2009 2:28:26 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
It's all in how you write the code. The most amazing tool will still be only as useful as a rock in the persons hands who doesn't know how to use it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Really, there are two goals here. As the originators of the technology, Parallax has a burden to make it as robust and error free as possible. Propeller accomplishes both of these things extremely well.
As users, clearly we apply the tech to whatever our particular goal is, and we may or may not see value in the various levels of abstraction possible above PASM, and this is where the differences are.
SPIN and PASM are the two lowest level, necessary tools we need for implementing the technology. The Propeller IDE is the basic interface required to interact with those. PASM is more or less perfect. The instructions do what they are supposed to do, and the only bizzare case I've ever seen was that guy who picked just exactly the right waitvid timing to be confusing. (wish that had been explored some) This is a remarkable accomplishment! ...and I think it's very easy to go under appreciated, given the norm we are used to seeing; namely, complex CPU's with errata covering various bits here and there that can be tolerated, or are discovered after enough units are in play to be a problem.
SPIN is just as robust, and the combination of the two demonstrate a very low overhead. It is quite possible to just pick up a Propeller, grab the tool and the manual and have something fairly complex up and running, with out a whole lot of extra understanding being necessary. This too is a notable accomplishment, and it too goes under appreciated largely because most of the people I've met, who grok the Prop and are into it, are actually extremely sharp people!
And as such, they are needy! (as most sharp people are, because they can see the better path and just want it!)
The other factor is time. It took 8 years for the Propeller I to be realized. Part of the value of that lies in the fact that one person basically worked through all the design and a whole lot of the test cases and made sure the thing just worked. This does not happen often today. The power of good enough is all around us, and I don't know about you guys, but it's quite something to actually be working with some technology where "good enough" just didn't cut it.
All of this combined really gets us to where SPIN and PASM are today.
Both are complete. It is possible to do the things that need to be done. Had Parallax shot higher where the core set of tools is concerned, the time involved may well have exceeded the time that makes sense. There is a window for these things, and missing it means failure across the board, for all practical purposes.
Today, we are not significantly limited by the design. The on-chip interpreter can easily execute any object SPIN code, be it the reference SPIN, or some more feature packed derivative. PASM has proven quite robust in that I'm quite sure NOBODY thought about the Large Memory Model at the design stage, yet we have it, and between those three, the Propeller has quite an array of rapid, robust and well balanced options for encoding it.
One of the things that's nice about these core tools is that they are easy to understand. Overhead is low, output is clean, easy to read, and the file format allows for a mostly self-documenting code, including schematics, and other things. Quite a package actually. There are simple means and methods to make changes to larger bodies of code, and with 32K, just how large of a body of code will there be? (seriously)
When I look at C code, libraries and other more complex things, available on somewhat more complicated environments, I see the ability to re-use code quickly being possible, but really that is only realized when those contributing code do it in such a way that re-using it makes sense! (Frankly, I've not seen this happen as much as I would like, and unless it's all MY code, it's a bit of a wash, all things considered.)
In this environment, I don't see those advanced things, but I have to say this is probably the easiest system for simply re-purposing code period. To an experienced hand, I'm sure it seems hobbling in some ways, but to the rest of us, it's just great! I, and others here, have been able to just look at various bits of code, actually understand what was being done, cut 'n paste, or better just write something in the context of what we were doing, and have that happen without a whole lot of hassles. As other have said, I can honestly say, I don't miss makefiles, paths and such one bit. It's simple, and when things get big, there is an extremely solid case for doing some planning to account for it as there is leveraging some advanced features. Both take time away from the task at hand, meaning this is more of an artifact of one's preference and experience, rather than being some core limitation that's a problem.
The COGs bring a wrinkle to this as well. On an ordinary linear CPU, blending code together as one body makes a whole lot of sense. Why? Because there is only ONE CPU! In the end, it's got to all play together at the higher levels or there is more trouble than just writing it full on as one body would have. Libraries then do add a lot of value as they can be incorporated and provide some level of compartmentalization that keeps things sane.
On the Propeller, it's entirely possible to just snag some code that does something useful, and run it on that COG, and not worry so much about the greater code body interactions, because the compartmentalization happens at the hardware level. IMHO, this is why the simpler tools make so much sense on the Propeller, when they really wouldn't on other more traditional CPU designs.
Having said all of that, I think the difference in scale with Propeller II, will bring some of the greater issues into play as the scope of possible tasks grows to a point where more advanced tool chains make better sense. I suspect Parallax will still continue providing a baseline NECESSARY set of tools, allowing those with the greater needs to fill them as they see fit. The core ideas behind the tech won't change, so why would the tools?
So there it is. It's not really a matter of useless. Just different. That's kind of where we are with the Propeller. It's a very different CPU. Those differences will absolutely manifest themselves in the tool chains that people use to interact with it.
Frankly, I like SPIN + PASM. It's very potent. Some of the other things called for, like conditional compilation, would be great, but they are absolutely not necessary to just get it done. I do find it interesting that the lack of that feature, in particular, has kept code readable and somewhat easy to re-purpose. If there is no conditional building of the code, good commenting and use of constants and such make sense right? Well, those are exactly the things that make the code simple to pick up and use in the first place! That probably sounds like blasphemy, but it's absolutely true in my experience, and I didn't expect it. I know others here have experienced the same thing.
Considering the lack of these more advanced things "omissions" to be "corrected" is a bit off the mark generally speaking. There are different philosophies surrounding how these things are done. Given the differences between Propeller and many other micro-controller designs, I think it's safe to say the omissions were deliberate with an intent closer to what I posted above, rather than some short cuts, or other thing to be corrected.
There's more than one way to look at it, that's all. Don't take my post as a flame either! I don't mean it that way. Just thought another perspective might put some of the differences into a context that might make better sense.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 1/6/2009 6:32:45 AM GMT
IMO Paul nailed it with that statement. Changes for the sake of changes isn't where its at.
That said, Spin is a nifty RAD language for micros more than anything else IMO. I'd love to see it on other micros like ARM and Coldfire.
I think it should be not to error-prone to make some additions to the IDE like conditional compilation for it changes not the SPIN language. So we should discuss two aspects: influencing the language and IDE
Post Edited (ErNa) : 1/6/2009 7:00:41 AM GMT
Not having easy to maintain and test tools and intellectual property is evidence of bad engineering and management. That also causes horrible delivery schedules.
Spin is fine and is easy to use. It is just limiting in several ways. Of course it opens eyes too and that's great.
@potatohead your posts are always great reading. Thanks for taking time to write them. There are many C libraries that are written in haste to get products out. They sit there for years until a new feature is needed after a hack here and there. When it's time to enhance the library there are two choices: continue hacking or rewrite. One is extrodinarily lucky if only one or two files need changes. Often in the C world people don't think about the effects of spreading changes accross many files until the codebase is so bug infested that people start leaving the company as the cancer eats all fortunes and liesure.
But that all takes place in large teams. Spin is used in small efforts. It will be harder to scale because of limits. Ya, I hate strings and strings of #ifdef #elseif .... #endif, but this goes away with inheritance and polymorphism. Still #include and judicuous conditional use is very helpful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
We can all try things (by using a conditional option). If it proves worthwhile, the users will decide to use the tools, and at no detriment to Parallax.
@jazzed: Spin on other processors: They use interrupts to control other features, and of course, they only have 1 cpu. I am not sure of the benefits for us or Parallax.
Currently I am busy doing a Cog emulation on the Xilinx Spartan 3A FPGA
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
cruising][noparse][[/noparse]url=http://www.bluemagic.biz]cruising[noparse][[/noparse]/url][/url]
This is a [noparse][[/noparse]b]bold[noparse][[/noparse]/b] test.
I think a pre-processor that does most of those things where the output is human readable SPIN, accepted by the propeller tool would be interesting. That way, the higher level constructs would be available, there would be some minor league overhead, but others choosing to just keep it simple and real, would still largely retain those favorable attributes present in the current environment.
As a counter point to your last post, it also goes away with a bit of planning too. As we move any direction away from the core set provided by Parallax, it's a matter of time. Just depends on how we all choose to spend it! And I think it's significant that this boundary was recognized as well as it was with the Propeller environment. I don't think that's an easy task.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 1/6/2009 4:16:45 PM GMT
What worries me is the resulting proliferation of languages fragments the community. Objects become incompatible. People don't want to have to learn many languages unnecessarily. Especially the traditional target audience of Parallax in education.
In a "professional" setting C might be preferred anyway.
I think what I am saying is that it is better to stick with Spin as it is as a standard. Any advancement of that standard would likely have to come from Parallax to stick.
Now a preprocessor I could probably welcome for handling those code configuration items like pin assignments or whether to use TV.Text or FullDuplex serial without having to hack the objects code. Use of such preprocessing tools could be added to BradC's IDE for example or used just from the command line.
There must already exist such preprocessors.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I got to thinking on this topic this morning. (sorry, I do that!)
The interaction among us and our experience levels highlights something else about the current reference Propeller environment that I believe is worth at least stating:
As I continue to learn more about this stuff, it has occured to me that most, if not all of my problems arise from either:
a. not having been exposed to the situation, so that's new learning
b. higher level feature dependency (just push the button without knowing what it does syndrome)
c. inexperience overall (just haven't done it enough to build body memory, meaning the mind is more engaged than it should be for the task at hand)
d. inability to obtain necessary information. (sparse documentation)
We are well down the path on d. Don't have that problem any more really. c. for me is a matter of time, no worries. b and a have relevance to this discussion!
Consider this thought exercise: (My day job involves adult learning advanced tools quite often, so that's where this is coming from.)
There was a time before the more advanced code constructs were available. Despite this, computing tasks were possible, meaning a lot of the work required to realize larger scale projects, in terms of either complexity or volume of code, was placed directly onto those working on the project. Habits then mattered. It's the usual lower level stuff, I'm sure most of us know well.
Those people, exposed to that time, carry forward and see the higher level advances as time savers, and use them when it makes sense. They can actually make that assessment because they understand how it's done at the lower levels, and can accomplish the goal sans the advanced constructs. Notably, the more advanced constructs evolved from those efforts to improve productivity. This is a necessary thing, however I don't think it's an exclusive thing, as in the lower level means and methods can be forgotten or marginalized.
Now, we've got people newer in the scene, who might not be getting that exposure to the degree that the old guard did! I could characterize myself as one of these people, as this is a hobby, potential career change situation for me. I love it, but have not practiced it in anything other than spotty ways since the 80's. So, I saw some stuff, missed out on other stuff. (that's just for context so this post is well understood)
So then, this newer group (and that's not a function of age, just exposure over time, and that's it) sees the higher level tools and learns to make use of them, but may not actually have been exposed to the lower level ways of doing things, just because. They then really cannot make that same assessment, and thus see these things as necessary.
I am absolutely not characterizing anyone here, just trying to make what I think is an interesting point.
So then, part of the Parallax business model is education. Specifically, it's education with practical uses attached. The idea being you can grok the stuff, then go out there and leverage that for your own purposes! Good stuff, BTW. Wish we had more companies like this.
In that spirit, doesn't it then make the best sense to focus on the core set of tools, so that said exposure is robust in this way?
As a circle around and look at my own growth, I think I'm in very little danger of developing a and b as greater things to be overcome at some future time, and I just can't see that as a bad thing overall. I'm also quite sure I would recommend a similar approach for others, as anything I've ever mastered in life has come down to understanding the core, fundamental things to a degree where little thought is required. In this, the current offering makes a huge amount of sense.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 1/6/2009 5:55:38 PM GMT