Any plans for a Propeller BASIC like PBASIC or SX/B in the next gen Propeller (

T&E Engineer

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.

Paul Baker

No, there are not plans at Parallax to release a BASIC for the Propeller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 9/28/2007 4:53:15 PM GMT

T&E Engineer

Ok. Thank you for your quick reply Paul. That answers that then.

Paul Baker

Bean is the author of SX/B, he is a third party developer, so perhaps a 3rd party will develop one, but we are not aware of any at the present moment that are working on it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

deSilva

AFAIK this question has never been answered. It was also my first reaction to SPIN: "Why didn_t they use somthing useful as Java or something established as PBASIC?" The raw power of SPIN is so low that you can hardly do it worse

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..

Mike Green

deSilva,
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.

deSilva

Mike, you hade very interting and instructive remarks wrt this topic! And they are fully in line with my own thought, especially wrt "limited ressources"

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

Rayman

I'm amazed that the SPIN interpreter can fit in one cog with <500 instructions. Given that, I think SPIN is pretty powerful. I do wish that they'd used a closer to C syntax though...

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.}

BradC

Rayman said...

{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!

Skogsgurra

A "programming virgin" like me (if you can imagine a virgin age 67 that has been programming diverse chips from the 4004 and onwards) as I said, a programming virgin that doesn't care much about the finer and deeper theories of programming, thinks that Spin is just as good - better actually - as many programming tools I have used. FORTH is an exception, of course.

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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Mike Green

I've mentioned before that an extended Pascal would actually be my favorite choice for a programming language for the Propeller. I've written Pascal compilers before and an operating system for the Z-80 using such an extended Pascal. There's a nice compiler for the Palm (Pocket Pascal) with about the right feature set that'll produce code for both the 68000 and ARM instruction sets and it runs on the Palm itself.

Sapieha

Hi All.

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

mcstar

I'm from a .Net C# background and can tell you that learning SPIN was extremely simply. There aren't that many commands, but what you can do with them is awesome. The fact that Spin closely follows the ASM code means that learning ASM has been even easier than I expected once I learned SPIN. Basic is fine, but it tends to dumb down the developer by hiding the essential concepts from them. The idea behind basic is to allow people to continue thinking in English, but still be able to program. To make really great software though, you have to think like the machine. The abstraction barrier it creates is very difficult to bridge if your only experience is in Basic. This phenmenon is common amonst Basic programmers. This is very similar to what happened when Microsoft released the C# lanagauge which was a step closer to the machine than the VB6 that was out there, yet much more expressive. Most .Net VBer's never learned to do object-oriented programming even though the .Net system is completly object oriented.

Bergamot

Well, I think we need to make a distinction between the structure of a language (how it's designed, what it can do) and its semantic presentation (curly braces, indentation, etc.)

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.

Mike Green

Sapieha,
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.

scotta

We should just create a C to spin converter, then call the compiler
(when the compiler is a DLL).

Same for Basic.

Sapieha

Hi Mike.

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

Mike Green

Parallax has already made clear that there will not be a DLL version of the compiler.
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.

hippy

I was dreading using Spin as it looked very alien to what I am used to, VB6, PBASIC, C, Pascal. In reality any worry was entirely unfounded and I've created what I'd call a substantial and credible piece of code as my first major project with virtually no problem in a very short period of time. Sometimes not noticing I've stuffed up indentation while cut and pasting has caused problems. I still naturally write >= and <= when I now need to use => and =< but otherwise I've found Spin a lot easier to code in fluently than I had expected. I personally still find it hard to instinctively understand var~ and var~~ but I am sure that will come with experience, and no one forces that syntax to be used when writing ones own code.

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

rjo_

T&E

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

rjo_

AND the Prop is just plain fun to work with.

T&amp;E Engineer

Wow...what a response!

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.

rjo_

Just out of curiousity... and to try to stimulate potential developer interest, how much would you be willing to spend for a complete Basic interpreter?

Rayman

You may want to know that somebody has apparently translated many of the BS2 commands into SPIN. This is the description in the "Object Exchange":

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.

Phil Pilgrim (PhiPi)

hippy said...
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

This is quite an intriguing possibility. It would probably best be implemented in Large Model assembly code, rather than in Spin, for speed. If you published a standard API for the more involved PBASIC commands, you could allow the user to create/customize their own routines for them in a way similar to the way OBJ is handled in Spin. For example, I may want to use my own background serial I/O routines, so I could write:

USE MySerial: SERSTART, SERIN, SEROUT

    ...

SERSTART InPin, OutPin, BaudMode

    ...

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

hippy

Phil Pilgrim (PhiPi) said...
This is quite an intriguing possibility. It would probably best be implemented in Large Model assembly code, rather than in Spin, for speed.

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.

Phil Pilgrim (PhiPi) said...
If you published a standard API for the more involved PBASIC commands, you could allow the user to create/customize their own routines for them in a way similar to the way OBJ is handled in Spin.

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.

scotta

Mike (Parallax)

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...

deSilva

Have a look at how Arriba handles that in PASD

Ariba

The better example to show how you can control the IDE is PreSpin:
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

deSilva

How could I have missed this nice piece of software? - Sorry Andy!