Any plans for a Propeller BASIC like PBASIC or SX/B in the next gen Propeller (
I'm not sure if this topic has come up in the past or not but...
One of the things that turned me off from the Propeller was having to learn another semi-difficult language (SPIN) or worse yet Assembler. I have grown up with BASIC as many have and would love to see something like this for the Propellor as a built in language. Yes I know there is Tiny Basic and the other one from Mike Green. I would just like to see something easier to use like PBASIC or SX/B as a supported language to grow with.
One of the things that turned me off from the Propeller was having to learn another semi-difficult language (SPIN) or worse yet Assembler. I have grown up with BASIC as many have and would love to see something like this for the Propellor as a built in language. Yes I know there is Tiny Basic and the other one from Mike Green. I would just like to see something easier to use like PBASIC or SX/B as a supported language to grow with.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 9/28/2007 4:53:15 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
I have now become aware of the constraints of a 500 instruction VM. Maybe somthing like SPIN is the best possible technical compromise? But surely not from the marketing point of view..
I would strongly disagree that "The raw power of SPIN is so low ...". Spin is functionally very similar to C which has been used for embedded computing for a long time, let alone more general system programming. That has its own problems and baggage, particularly with the standard version and when you include the libraries. Spin happens to be very well matched to the underlying hardware (no surprise!) and follows in the footsteps of some very well thought out low level programming languages like PL360.
Java, while ubiquitous now, is not a very good match to something like the Propeller. To be really useful (Javelin aside), Java needs a memory manager and that would add extremely variable unpredictability to the execution times. I know it's possible to make a memory manager for use with real-time systems with predictable impacts on execution time, but it's much harder than not having one at all. PBasic, while the basis of most of Parallax's products, is very limited. It's higher level statements are convenient, but not good matches to the Propellor's capabilities. PBasic is also extremely weak on subroutine/function calls and has no provisions for scope of variables at all, both extremely important for large programs. From a marketing perspective, it might have been useful to have a PBasic for the Propeller as a transition tool, but resources being as they are, starting with Spin was a good choice. It still would be useful to have a PBasic to Spin compiler that turns out Spin source code and references the existing compatibility library. It would be messy to actually use given that the Propeller Tool doesn't have any provisions for a compiler pre-processor, but it would be doable. Again, the problem is one of limited resources.
On the other hand I should fiercely contradict some of your assessments of the merrits of SPIN compared to a few alternatives you mention. But this is truely another story to be discussed best in a very different forum at all
But, the more powerful a language, the steeper the learning curve, I think... I have a feeling that most users are hobbyist, so I think SPIN is probably as advanced a language as you'd want anyway.
At first, I was skeptical about SPIN. But, now I think it's pretty good.
{My only gripes are having to use ":=" instead of just "=". Also, I think code would be much clearer if a function call with no arguments would still need "()" beside it. And I don't see why I can't preset the value of variables in the "VAR" section.}
It reminds me very much of Pascal in that regard actually. As a pascal programmer from way back it suit's me down to the ground!
As long as the main complaint is that Spin should be a problem to learn and use, I do not think that one should care too much. And the comparison with Stamp Basic is really hard to understand. Stamp Basic is hardly Basic. Not even GW Basic.
Spin is just right for this chip. And if you need more power, there's a fun and intelligent assembler.
But. I haven't applied any programming science to this thinking. I just see that I get very nice results. And fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
In obedience to me that not language in which I write program but his possibilities of memory management is major.
But as now small possibilities of memory management have Propeller Tools.
1. Possibility of Org for VAR
2. Load possibility COG and release memory.
3. Laying-on of COG ASM of routiner so on release memory the free memory makes one block.
I can count anymore but or it has some goal ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
I have no doubt that Parallax could have made SPIN look a lot more basic-y than it does, without changing the structure or the bytecode interpreter at all. Would that have made it better? Ehh, it's largely a matter of opinion.
You are not going to see much change in Spin or the Spin compiler, certainly not a major change like the addition of memory management such as you describe. I don't know what the C compiler from Image Craft will look like. You might look at their other compilers to get some idea.
Keep in mind that Parallax has very very limited resources for software development and they give away their software products, so they're not going to be hiring more people for software development any time soon. Changes such as you and others have suggested seem reasonable, even necessary at times, but they're unlikely to be done. If you look at the very small changes that have been done to Spin, they are really very simple ... like allowing "$" to refer to the current location in assembly or they're changes to the IDE.
(when the compiler is a DLL).
Same for Basic.
I will not have change in Spin but only litle more capabilities in compiler.
So I can use Spin more structured and optimized.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
You don't have to wait ... you can write a C to Spin or Basic to Spin converter and produce a text file
that you can compile manually.
There are aspects of the language ( and Propeller Tool ) which I do not like, functionality I find missing, and things I would have done differently, but that goes for all languages I've had to use. The only real problem I've run into has been in understanding how to create user-defined characters for video output, and that can hardly be blamed on Spin.
Going back to programming other microcontrollers I have found myself thinking it sure would be nice if Spin were available for those
It is entirely possible to write a PBASIC to Spin converter and, even though the Spin bytecode is not documented ( and will not be by Parallax ), enough information has been unearthed to make a third party PBASIC to .eeprom compiler entirely feasible. Having investigated both, the later is more appropriate as Spin has no Goto statement, and PBASIC is frequently used in a non block structured manner. A VB6-style block-structured PBASIC wouldn't be a problem either way.
Another alternative is to completely emulate a Basic Stamp at the Tokenised Code level so a Propeller can be used as if it were a Stamp and all the familiar PBASIC tools can be used -- I can guarantee you'll hear more about that in the near future
I am an end user, with no special relationship to Parallax.
I am as close to a complete idiot as exists in this forum when it comes to formal programming experience.
I strongly disagree with the notion that Spin has a steep learning curve. I didn't study it at all...I went straight to Propeller Assembly (where the curve is real... real steep for me... mostly because I have no engineering background and don't have a store of knowledge to understand the volumes and volumes and volumes of available... and well documented... examples.
I find Spin to be a completely natural language. If Spin has anything a of learning curve, it is only because Chip threw 8 cogs into the brew and he left complete control of the cogs up to the programmer. That takes some time to get your brain around. Any higher level language approach to the Prop would also limit the programmer in some respect.
Controllers themselves take a different mind-set and level of understanding than normal programming... I think that is where the real learning curve comes in and that has nothing to do with Spin. So, if controllers are where you are at and have been for a while, don't worry about Spin.
One of the closet secrets about the Propeller is the counter architecture. Many controls can be set up with a simple counter set-up(and every cog has two of them[noparse]:)[/noparse] Complaints about speed are sometimes from people that aren't using counters effectively. By using the very nice counter architecture, your program is free to do other things while the counters do the dirty work.
The half-life of your time investment is the real killer in business... with the Prop, everything you learn has value and will probably retain that value for your working life-time.
That's pretty rare these days.
Rich
I once had a Propstick and a Hydra but later sold it on eBay after reading through the Hydra manual (and it fell apart on me - many pages came out). I really did not want to spend the time on another harder language (than BASIC). As not being a C programmer (or really any - more of a hardware type·engineer / hobbiest), I have tried to keep it simple with BASIC like languages.
As I have read in this post, SPIN is alot like C which I have not really dealt with before (C that is). It takes up most of my time just trying to keep up with JonnyMac and Bean (for example) with SX/B and PBASIC.
This was the reason for my initial question. If someone ever does write a BASIC like interpretor for the Propeller that is complete like SX/B and PBASIC, I will be the first in line.
All in all, I am very happy with SX/B and PBASIC and just wanted to ask about the Propeller, that's all.
Thanks for the great flow of interest.
BS2 Functions
General PBASIC functionality library, written in Spin, that mimics and extends many popular BS2 functions: COUNT, DEBUG, DEBUGIN, FREQOUT, PAUSE, PULSOUT, PULSIN, PWM, RCTIME, SEROUT, SERIN, SHIFTOUT, SHIFTIN.
This would establish a connection between the PBASIC commands SERIN and SEROUT, and routines in the module MySerial of the same name. It would also create a new command SERSTART that starts the cog that does the background I/O.
'Don't mean to complicate things, but the ability to extend and customize a language is a Good Thing. (It's one reason I'm so hot to get pre-processor hooks built into Spin.
-Phil
Agreed, but I've only had my Propeller Chip three weeks and haven't really got to grips with Assembler. Plus I got distracted with USB, Video Displays, and Speech Synthesis - rjo_ is entirely right, the Propeller is really good fun, distractingly so ! I basically chose this as my first application because it would force me to learn Spin and it's worked very well. I've tripped up on a few things, but it's been mainly plain sailing.
The big execution time overhead in the emulator when using other micros is extracting bit aligned bytecode tokens but the built-in multi-bit shifts and 32-bit words makes that a breeze in Spin. Unfortunately the overhead in Spin moves to its Case statement for dispatching the bytecode handlers, and hence my recent posting on the desirability of an 'ON Var GOSUB' type command, or some sort of jump table handling.
It's a possibility and would be interesting. The big question is how to get the 'PBASIC Objects' into the Emulated Stamp and the compiler tools needed to allow the programmer to use them. I'm only working on emulating a BS1 / PBASIC 1.0 at present and the approach I've used is to subvert existing commands so the extensions are relatively logical.
I'm with you all the way on adding pre-processor hooks to the Propeller Tool.
I don't care if Parallax produces a DLL library with wrappers
for C/C++/C#, I would just like to trigger the complier with
a script.
The system call on linux would do this...
http://forums.parallax.com/showthread.php?p=655470
PreSpin is an IDE-Extension that gives the functions to implement all kind of Precompilers. It has already a built in Preprocessor for conditional Compilation and including other files at any place.
I use it very often for my projects, the only disadvantage is that the Spin Error Messages appears in the preprocessed version of the Source, and you have to edit the code in the original source.
Andy