Cluso99 said> "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."
The interrupts thingy is not a problem to me. Most single core CPU have multitasking o/s code support which can be leveraged in similar ways as using a separate cores. Propogating Spin to other platforms has enormous potential for Parallax. It's a market mind-share thingy. So many people here are so enamoured with Spin that it should indicate great potential for the language ....
@potatohead: There is a spin programming for beginners thread that is very good. There are many advanced programming threads. Techniques are available to solve some advanced problems that are not immediately obvious. Phil's Tricks & Traps thread is a great read.
@soshimo: I use the containment approach all the time. Main problem is one has to add more getter/setter accessors to access the "inherited" member properties - this eats up memory some, but is mostly a performance issue. Spin is already slow (fair optimization of speed/space) and adding another layer of method calls is just makes it worse. If you have a good example that solves this main problem, I'm all ears.
@jazzed - From what I've heard the Spin interpreter is pretty tight and the amount of effort required just to gain even an extra 1% of performance is just cost prohibiting and wouldn't buy you much already since it's pretty efficient. Remember, these are ucontrollers running at 20MIPS (for each core), they are not intel core 2s running that are 18MIPS per MHZ (at 3.2GHZ they run over 50kMIPS). If you want tight efficient code, write assembler. That's pretty much been the case throughout history and still is today - most ASICS I've worked on have been at least 50% assembler (cell phone ASICS seem to be the exception, at least at Qualcomm/KWC it was mostly ANSI C - but some of the tightest C code I've ever seen). I don't mean to give you my resume, just want to give you my point of view in case it's skewed as I've been out of the wireless sector for about 4 years now and things may have changed significantly.
I recommend instumenting SPIN code with bit toggling and measuring with an o-scope so that you may understand.
Edit: Actually, there is a trick that I forgot that can make getter/setter time faster so the impact is much less. Requires more coding though. Look for Hippy's abort code: http://forums.parallax.com/showthread.php?p=575479
Why don't you save me the time and effort (and cost to fix my borked oscope) and tell me what you found already? Or at least share a link that already has this information in case it's in some obviously obscure place.
Besides, how did this get from features of the language to optimizations of the Spin Interpreter? It's sounding a bit of an Ad Hominem. Shall we return to the original discussion of what the community wants? Which I think a lot have already spoken - they want to learn to harness the power of what they have now before looking behind other doors.
Sure. I'll produce before end of day tomorrow if I have enough time using analog scope readings. If you feel like it, you can reproduce similar results later with Paul's digital scope ... http://forums.parallax.com/forums/default.aspx?f=25&m=145310
Answering your edit: Because it follows on with an analysis of why inheritance or allowing some public variable access would be useful.
Is there a way to call Propeller.exe and pass it the name of a SPIN file to load? If not, may I suggest this feature be added?
My background goes back to the "olde dayes" when in order to get an executable, you would edit the code, exit the editor, run the preprocessor, run the compiler, and run the linker, with pauses in between to fix any errors. IF Propeller.exe accepts a file name to load, then a number of tools can be run before the IDE. A couple of favorites would be LEO (http://sourceforge.net/projects/leo/), a preprocessor (I use mcpp from work, but there are many out there), and/or Draft Code Generator ( http://www.simtel.net/product.php?id=37145&sekid=0&SiteID=simtel.net)
Also ... this slipped my mind, but does work for scripting if you have a cpp preprocessor executable:
spin fragment
{
#ifdef ENABLE_SOME_FEATURE
}
' some spin code to enable here
{
#endif
//ENABLE_SOME_FEATURE
}
If you want to see how many prop instructions (hence cycles) per spin instruction, try my Spin debugger (see link in my signature). It counts the instructions (because it is actually single stepping through them).
As promised, here are some relative spin measurements done with an O-Scope.
See the MethodCall.spin file for data.
Some result offer minor suprizes that affirm the value of examination.
Which is faster ceteris paribus?· "return value" or "result := value" ?
@Cluso99:
I would love to use your Interpreter/Debugger, but it's not clear what to use or how to do it.
Certainly
4 # Fully integrated IDE C-like preprocessor #defines and conditionals.
5 # Fully integrated IDE preprocessor #include statement for any valid code or #defines.
should be safe and easy to add ?
(even if done with some 3rd party wrapers, but transparent in the IDE )
I'd find it very hard to work without conditional compiles in any language.
If people need Make, #defines, C++ OOP features, conditional compilation, pre-processors, etc just use ImageCraft C or port over the GNU C++ tool set and Eclipse instead of mutating Spin into some sort of weird C++ subset.
The other thing that concerns me that by making Spin more complex and bug prone its going to drive away newbies when they see some the code gibberish that will be the result of this added complexity.
It's obvious there is nothing to fear on SPIN mutating ... or evolving for that matter.
My first post in this thread acknowledged the futility at the outset of asking for anything.
I welcome the fact that Parallax got beyond 20 goto 10 BASIC with Propeller ...
and if you really must have BASIC that's available too.
I will close with this in appreciation of the effort it took to make it happen:
The command line version of PropTool actually does address some items.
* The ability to specify a path for includes and library objects.
* Pre-compile and post-compile tool command ... not integrated but fine.
Again, one can force a precompiler to work outside the IDE as mentioned before.
It was never my intent by starting this thread to insult anyone. Don't take it that way.
I wish Parallax the best of luck in their increasingly competitve market niche.
Agreed. Besides, these can just exist in custom posts!
From there, as long as the output is sane, anyone can pick up the output and use that, at a minimum. Spin is really clean. Love that part about it. It is just not hard to read or parse, but for all the little one or two character shortcuts.
Nice features though. Kind of hard not to add them. And if they are gonna be there, the shortcuts are probably better than longer keywords.
Just to add a slightly different voice: I don't consider SPIN to be a particularly interesting language.
Look at the Arduino environment for a lesson on how C/C++ can be made user-friendly without loosing any of the capabilities of C.
And there is no lack of easy to use libraries to interface to all sorts of hardware etc with the arduino.
SPIN just another different programming language, with its own idiosyncrasies and real limitations and no great merit to overcome
the "its just different" hurdle.
I play with propellers for a hobby so it doesn't bug be overmuch. But I'm sure that for more commercial interests this could be a real problem.
This is a bit of a shame, as the propeller hardware is very interesting and a very different take on the compromises usually made when
designing a new microcontroller.
Comments
The interrupts thingy is not a problem to me. Most single core CPU have multitasking o/s code support which can be leveraged in similar ways as using a separate cores. Propogating Spin to other platforms has enormous potential for Parallax. It's a market mind-share thingy. So many people here are so enamoured with Spin that it should indicate great potential for the language ....
@potatohead: There is a spin programming for beginners thread that is very good. There are many advanced programming threads. Techniques are available to solve some advanced problems that are not immediately obvious. Phil's Tricks & Traps thread is a great read.
@soshimo: I use the containment approach all the time. Main problem is one has to add more getter/setter accessors to access the "inherited" member properties - this eats up memory some, but is mostly a performance issue. Spin is already slow (fair optimization of speed/space) and adding another layer of method calls is just makes it worse. If you have a good example that solves this main problem, I'm all ears.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Edit: Actually, there is a trick that I forgot that can make getter/setter time faster so the impact is much less. Requires more coding though. Look for Hippy's abort code: http://forums.parallax.com/showthread.php?p=575479
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Post Edited (jazzed) : 1/6/2009 8:07:21 PM GMT
Besides, how did this get from features of the language to optimizations of the Spin Interpreter? It's sounding a bit of an Ad Hominem. Shall we return to the original discussion of what the community wants? Which I think a lot have already spoken - they want to learn to harness the power of what they have now before looking behind other doors.
Post Edited (soshimo) : 1/6/2009 8:15:05 PM GMT
Answering your edit: Because it follows on with an analysis of why inheritance or allowing some public variable access would be useful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Post Edited (jazzed) : 1/6/2009 8:24:42 PM GMT
My background goes back to the "olde dayes" when in order to get an executable, you would edit the code, exit the editor, run the preprocessor, run the compiler, and run the linker, with pauses in between to fix any errors. IF Propeller.exe accepts a file name to load, then a number of tools can be run before the IDE. A couple of favorites would be LEO (http://sourceforge.net/projects/leo/), a preprocessor (I use mcpp from work, but there are many out there), and/or Draft Code Generator ( http://www.simtel.net/product.php?id=37145&sekid=0&SiteID=simtel.net)
--Rich
Try this: http://www.parallax.com/Portals/0/Downloads/sw/propeller/Propellent-v1.1.zip
Also ... this slipped my mind, but does work for scripting if you have a cpp preprocessor executable:
spin fragment
{
#ifdef ENABLE_SOME_FEATURE
}
' some spin code to enable here
{
#endif
//ENABLE_SOME_FEATURE
}
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
That's my $.02
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
See the MethodCall.spin file for data.
Some result offer minor suprizes that affirm the value of examination.
Which is faster ceteris paribus?· "return value" or "result := value" ?
@Cluso99:
I would love to use your Interpreter/Debugger, but it's not clear what to use or how to do it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Certainly
4 # Fully integrated IDE C-like preprocessor #defines and conditionals.
5 # Fully integrated IDE preprocessor #include statement for any valid code or #defines.
should be safe and easy to add ?
(even if done with some 3rd party wrapers, but transparent in the IDE )
I'd find it very hard to work without conditional compiles in any language.
The other thing that concerns me that by making Spin more complex and bug prone its going to drive away newbies when they see some the code gibberish that will be the result of this added complexity.
My first post in this thread acknowledged the futility at the outset of asking for anything.
I welcome the fact that Parallax got beyond 20 goto 10 BASIC with Propeller ...
and if you really must have BASIC that's available too.
I will close with this in appreciation of the effort it took to make it happen:
The command line version of PropTool actually does address some items.
* The ability to specify a path for includes and library objects.
* Pre-compile and post-compile tool command ... not integrated but fine.
Again, one can force a precompiler to work outside the IDE as mentioned before.
It was never my intent by starting this thread to insult anyone. Don't take it that way.
I wish Parallax the best of luck in their increasingly competitve market niche.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
From there, as long as the output is sane, anyone can pick up the output and use that, at a minimum. Spin is really clean. Love that part about it. It is just not hard to read or parse, but for all the little one or two character shortcuts.
Nice features though. Kind of hard not to add them. And if they are gonna be there, the shortcuts are probably better than longer keywords.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!
Look at the Arduino environment for a lesson on how C/C++ can be made user-friendly without loosing any of the capabilities of C.
And there is no lack of easy to use libraries to interface to all sorts of hardware etc with the arduino.
SPIN just another different programming language, with its own idiosyncrasies and real limitations and no great merit to overcome
the "its just different" hurdle.
I play with propellers for a hobby so it doesn't bug be overmuch. But I'm sure that for more commercial interests this could be a real problem.
This is a bit of a shame, as the propeller hardware is very interesting and a very different take on the compromises usually made when
designing a new microcontroller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo