The Official "Future of PropBASIC" Discussion Thread (Feb 2016)
Bean
Posts: 8,129
in Propeller 1
As you may or may not know, PropBASIC was actually designed to be a PASM learning tool. As such it is not feature rich, for example you can only have one math operator per line and you cannot do math in anything other than a variable assignment.
I think I (We) have to make a decision if we want PropBASIC to remain a PASM learning tool? Or do we want it to be a full featured language in it own right?
I am leaning towards making it full featured. Much more like standard BASIC. That means a complete expression evaluation any time a value is expected, a stack for passing values to subroutines, etc.
This will make the compiled programs larger, and I really cannot see any sense in supporting native code as only very small programs would fit. Maybe support native code for TASK that are 100% PASM.
My other idea is to forget about a compiler and design an embedded BASIC. If you haven't seen it I wrote an embedded BASIC for the P1 for the Parallax Spinneret design contest. It was called PE-BASIC (Propeller Embedded BASIC) and was written in PropBASIC.
On the P2 this could be a very powerful language without the need for any external computer. It could be either controlled by a terminal program (serial input/output) or a PS/2 keyboard and VGA monitor.
Embedded BASIC would be nice because you don't have to worry about what OS or machine you are using. In fact PE-BASIC was able to be controlled via telnet on the Spinneret.
The P1 is kind of limited in RAM for this, but the P2 is a whole new story. I think a very power embedded BASIC could be written for the P2.
I know the speed won't be nearly as fast, but the PE-BASIC was pretty fast and MUCH faster than a Basic Stamp and those are used a lot.
Anyway that is my thoughts at the moment. I'd like to hear what PropBASIC user think.
Bean
I think I (We) have to make a decision if we want PropBASIC to remain a PASM learning tool? Or do we want it to be a full featured language in it own right?
I am leaning towards making it full featured. Much more like standard BASIC. That means a complete expression evaluation any time a value is expected, a stack for passing values to subroutines, etc.
This will make the compiled programs larger, and I really cannot see any sense in supporting native code as only very small programs would fit. Maybe support native code for TASK that are 100% PASM.
My other idea is to forget about a compiler and design an embedded BASIC. If you haven't seen it I wrote an embedded BASIC for the P1 for the Parallax Spinneret design contest. It was called PE-BASIC (Propeller Embedded BASIC) and was written in PropBASIC.
On the P2 this could be a very powerful language without the need for any external computer. It could be either controlled by a terminal program (serial input/output) or a PS/2 keyboard and VGA monitor.
Embedded BASIC would be nice because you don't have to worry about what OS or machine you are using. In fact PE-BASIC was able to be controlled via telnet on the Spinneret.
The P1 is kind of limited in RAM for this, but the P2 is a whole new story. I think a very power embedded BASIC could be written for the P2.
I know the speed won't be nearly as fast, but the PE-BASIC was pretty fast and MUCH faster than a Basic Stamp and those are used a lot.
Anyway that is my thoughts at the moment. I'd like to hear what PropBASIC user think.
Bean
Comments
Note that PE-BASIC does have a full expression evaluation.
Bean
-Mike
With this being in VCS now, this easy. Create a branch for v2.0 and then continue development of both projects! Or, even fork it off as a project with a different name
But I agree with Mike, it definitely sounds like you (someone) should keep both of these alive. They each have their merits.
Existing feature set of PropBASIC ... I have not found these to be limiting.
Full feature with larger compiled size ... nice to have, but not at the expense of any significant size.
Embedded ... does not add value for me.
As a hobbyist, it would delight me to use the same stable platform for a decade or more (hardware, language, IDE, etc.). Maybe I am the only Luddite that would not be thrilled to move to P2, gobble up more RAM, and use a different development scheme?
Regarding the future, if you go in the direction you say you would prefer, you'll lose some current users but you may pick up many more if you focus on making PropBasic a migration path from the Basic Stamp to Prop hardware. If you do write an embedded Basic for the Prop 2 that looks fairly familiar to Stamp users, I would think that would be an environment they would find much more comfortable than C or even Spin. I've long considered the lack of such a Basic-language migration path to be a major hole in the Parallax product line.
Certainly, grow the features toward more standard basics.
Do you have any 'standard basics' references in mind ? I've found FreeBASIC to be quite good for simple PC scripting work.
This has Conditional Compile
http://bourabai.kz/einf/freebasic/TutConditionalCompilation.html
I don't see that making it full featured has to close any doors tho, and any existing PropBASIC code would surely be the same size (or even smaller) ?
I can see that new code, with more complex expressions might be larger as it creates temporary vars or uses a stack, but even here, it should not be wildly different to the manual example above ?
That creates 5 temporary VARS, and a Compiler can start to overlay such temp variables within functions it knows never call each other.
Taking that CRC example above, and roughly porting the line, this compiles in FreeBASIC
It can do both, surely ?
How quickly can PropASIC be made to generate P2 code ?
Using it like a Structured Assembler, would make code more portable between P1 and P2.
I'm not quite following ?
PropBASIC would be able to do BASIC -> PASM, within the usual COG limitations surely ?
( And, eventually BASIC -> HubExec PASM2 ? )
Which compile modes can PropBASIC support now ?
Well put, Mike.
I need PASM speed and prefer to focus on WHAT I need to achieve rather than HOW to achieve it, as would be the case if I had to use pure PASM.
I don't regard PropBasic as a learning tool for PASM, for me, it's a RAD tool for PASM.
Yup and as P2 releases, it will gain importance (Assuming a PropBASIC P2 code generation switch) as a means to develop for both P1 and P2.
Are there any current PropBasic users who think the ability to write native cog code is not important? It's Bean's work so it's Bean's call, but I think this represents a change that will appeal to a different set of users, not a superset of current users. That may not be bad, considering that we've had a hard time getting enough people interested to justify support from Parallax. I DO think a case can be made for the Basic Bean talked about, but I think such a Basic has a different target user base, and how large that potential base may be I have no idea.
I wonder if a thread on the Basic Stamp forum would be useful, to see what sort of interest there might be among Stamp users? They may not even look at the Prop forum. Wouldn't they be the main group of potential users, as Parallax customers who probably know about the Prop and who are already current Basic users?
Good 'either-core' support is where PropBASIC should be able to shine, as it has much less constraint than GCC.
-Mike
Addendum: The native code capability is very important to me, for sure.
Edit: A couple of words were changed in the above for clarity.
If PropBASIC can be made to work simply and reliably with the other associate tools, then it becomes more of a candidate for Basic Stamp.
The other approach, for inbuilt Basic, is to simply clone Basic Stamp, so that code can run on P1 or P2.
This focuses more on backward compatible, than features. It only has to run Basic Stamp Code.
Both FreeBASIC and FreePascal have compiler compatibility switches, so that is another choice if Basic Stamp and PropBASIC are close, but not identical.
Has anyone listed the differences ?
You're saying that C, which is supposed to be cross platform, will be less portable than a language designed with exactly one chip in mind?
P1 GCC is stuck with an 'other core' register model code generator, designed to fit with low register count RISC, and P2 will likely be the same. That's easy to do, and works, but is less than optimal.
PropBASIC is already ahead in that area.
Being larger, GCC has a lot more inertia, and the Code generator is harder to work on, that means changes are slower, and even release of P2 support is of undefined timeline.
GCC also struggles somewhat with ASM and mixing ASM & C, again constrained by having to support many cores.
PropBASIC should be able to mix PASM and Basic, in smarter ways than GCC.
I've been thinking about this.
I feel Beans pain.
If I re-call correctly something like this came up a while ago when Bean announced his intention to do something similar as he is now proposing - its obviously something close to his heart - and it wasn't accepted with (lets say) enthusiasm!
In fact, when I see some of the negativity towards Basic as a language, and the lack of refinement of PropBasic as it is, (even though it works perfectly well if you give it a bit of thought), I wonder why Bean bothers at all - I would have given up years ago- but Bean hasn't and I applaud him.
I will be really happy to have a P2 version of what we have now, not being able evaluate complicated expressions on one line doesn't bother me at all.
Now if that can be done without a complete redesign, i.e. without an undue amount of effort (for Bean - for me it would be impossible...), then I say do that and then- follow your heart and make a full featured (slower) or embedded Basic (slower again?), with all the bobs and whistles- I will certainly have a play. But if it doesn't go at full P2 asm speed, then it will be second class (for me); although if that's the only Basic for P2 then I will use it.
Now its possible that this new Basic peforms so well with the new P2 silicon, I will do an about turn and embrace it; but, I do like to 'bit bang' at maximum speed, writing my own I2C, SPI, PWM and uart, multiplexing etc etc just out of fun, and if I can't generate assembler and then tweak the result, some of the fun will be lost.
BUT- I hope you find the time for both - a P2 version of what we have now, and whatever you heart dictates, for sure they will both be used by grateful recipients, including me.
I for one am very grateful for the PropBasic we have now- and I await your decision with baited breath.
Dave
Hear hear!
If Terry had a "Donate" button somewhere, I for one would be a regular clicker.
"Free" and "open" are unimportant to me. I have to pay for everything else in life.
With the posts revealing that much, I think that the PropBasic 1.44 binaries should be released to the wild, and then maybe the "mooring lines" for PropBasic should be cut, with a final note, "...be sure to write".
Now, there has been mention about PE-BASIC, maybe Bean should go that route, but will you get more than a handful of users with that derivative?
I do not think that the concept of using BASIC is the problem, I think maybe some more effort should be made towards a proper presentation for users of BASIC, or users that are interested in using BASIC on a Propeller. I say that, because if you really read the documentation for PropBasic, with the bias set aside, you will discover that the docs are for people that have a familiarity with Spin to begin with. Your new user, probably has no interest in that area, otherwise that would be the starting point.
So, where are we at now?
Ray
Although I like Spin, I know very little apart from playing with and modifying others' code.
I am by no means an accomplished programmer, I cannot hold a candle to the other contributors to this forum. However, I jumped right in to the Prop world using PropBasic and I have amazed myself with what I am able to achieve. The only question that I remember having to ask was regarding setting up PWM. It looked too easy and it turned out to be. :-D
But I've always wondered what would happen if I implement a Basic interpreter on the Tachyon kernel which would then take advantage of the speed and compactness of the Tachyon VM as well as all the many many extensions and drivers included VGA, FAT32 and Ethernet servers etc. To me that would just be a layer like any other layer. So the code would be compiled into Tachyon byte-code instructions which have a minimum cycle time of 400ns @80Mhz and most are less than 1us.
The funny thing is that other than being aware of the stack that there are some areas where there isn't a lot of differences with Forth and Basic, for instance:
Basic: HIGH 23
Forth: 23 HIGH
Basic: PRINT"HELLO WORLD"
Forth: PRINT" HELLO WORLD"
Basic: 2 SHL 3
Forth: 2 3 SHL
Basic: LCD CHR$(12);
Forth: LCD 12 EMIT
Basic: FOR A = 1 TO 10
Forth: 10 FOR ....... NEXT
Basic: PAUSE 1000
Forth: 1000 ms
etc
Just throwing this thought out there.
Oh sure. There are those who are combining the LMM mode with cog mode.
For me, it's not so much about being a standard basic but a means of being able to generate PASM code using a syntax that is familiar to BASIC programmers.
Hey, now this is the kind of tutorial that I need to get me to play with Forth!!!
VGA $100 $20 DO I EMIT LOOP CON
and have it spit out all the printable 8-bit characters on the VGA as soon as I hit the enter key, yes!
Looking at the simple Basic FOR NEXT:
10 FOR a=1 to 10
20 PRINT a
30 NEXT a
vs Tachyon where we use a DO LOOP which allows a starting index (1) and a stop at limit (11) and access to that index as I amongst many other things:
11 1 DO I PRINT CR LOOP
There is no GOSUB in Forth as functions are named much as they are in Spin and any reference to them generates an implicit call such as:
pub DEMO 11 1 DO I PRINT CR LOOP ;
then run that with:
DEMO
or build it in to another function:
pub STUCK BEGIN CLS DEMO 1 second ESC? UNTIL ;
which when "called" will simply clear the screen, run DEMO, wait one second, and continue from BEGIN until an escape key is pressed.
Since Forth is fast and interactive I find that the best way to learn is just sit at the terminal screen and try simple stuff such as is outlined in the Introduction to Tachyon Forth as linked in my sig. There are some major differences with Basic of course but being able to test it out immediately makes it so easy to verify methods etc.
Anyway if Basic programmers want to program in Basic then adding this layer is one solution. As mentioned Tachyon is built for speed and it is much faster than Spin and the real test is in real programs and use, which is where my filesystem and Ethernet really perform for instance, without dedicating anything to a PASM cog other than the VGA and serial driver. All SPI operations use a very fast SPIxx instruction for instance. Any Basic built on top of all this will simply benefit from it.
And it has done a very good job, but it the source is kind of a jumble as it was started long ago for the SX processor.
It's main goal is to write tight code (because the SX has a small code space that was paged, and Propeller can only have 496 instructions) so it kind of handles everything as a special case.
This makes if very hard to for instance add a new variable type.
I was thinking about just starting over. And what would be my goals if I did that.
Native code is really restrictive because of the size (only 496 instructions), but it is really fast and required for video drivers and such.
LMM code is pretty fast, and large and seems like good method of "most" code.
Expression evaluation is really nice, but leads to larger code.
An embedded language would be "cool" and be nice for beginners since you don't have to worry about OS's compatibility, etc. Could be serial, WiFi, VGA/Keyboard etc. But it is really slow...
Since this work will be done on my dime, I will have to sit down and really think about what I need and want.
I really appreciate all of the input you guys have, it gives me more to think about.
If I was making something that would be sold, I think I would do an embedded BASIC with WiFi access. I think that would be the most popular (maybe not the most useful).
Bean