PDA

View Full Version : Propeller BASIC compiler ideas...



Bean
07-16-2009, 08:19 PM
I was thinking about just messing around with a BASIC compiler for the Propeller. Which to do you think would be most useful:

A) BASIC to Propeller Assembly
······ Could use to make video/hardware drivers
······ Limited to 497 assembly instructions


B) BASIC to Spin Tokens
······ Large programs possible
······ Same speed as spin code
·······Easiest to implement compiler


C) BASIC to LMM Assembly
········Not as fast as PASM
······· Large programs possible
······· Hardest to implement compiler

Which option do you think would be the most useful. And why.

Bean.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...


·

BradC
07-16-2009, 08:33 PM
This is a really tough one. I figure if Parallax could have made BASIC do what they wanted to get out of the chip they would have used that rather than creating SPIN.

A) is limited by code size but would go like a bat out of hell. B) is just re-packaging SPIN for those who won't learn another language. C) has the disadvantages of C (lower code density than SPIN and less speed than PASM) plus the extra complexity of the compiler without the global compatibility that actually makes the language attractive.

Personally I'd be targeting B to start with. It's much easier to implement and will likely attract people that currently use the stamps and their clones who are looking for more horsepower. You could then offer a variant back end later that had an LMM target as a bit of a challenge if you were bored ;)

Having said that, I'm also not a likely target, nor am I developing it.. so I probably need to give a huge discount on my .2c worth.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

trodoss
07-16-2009, 08:40 PM
I would opt for option 'B' for a BASIC compiler, since it would be easier to implement, and should perform well for most BASIC apps. Are you planning on writing a PBASIC-like compiler, or are you going for a basic variant like PowerBasic/FreeBasic?

MagIO2
07-16-2009, 08:53 PM
Why not support all possibilities? You could have a compile directive which tells the compiler which block to compile in which way.

I think there is no big difference in BASIC to PASM compared to BASIC to LMM. My understanding is that the jumps and calls have to be treated different whereas the rest is pretty much the same.

And as you say BASIC to SPIN is the easiest you can add this as well ;o)

Or what about having BASIC to SPIN plus inline PASM? So you don't have to switch development environment if you want to do some stuff in PASM.

Just my half a cent ...

BradC
07-16-2009, 09:05 PM
MagIO2 said...

Or what about having BASIC to SPIN plus inline PASM? So you don't have to switch development environment if you want to do some stuff in PASM.



You can't do that. If you are working in the SPIN interpreter, the only real way to run some PASM is to launch another cog. Nobody has come up with a modified interpreter that will allow you to inline PASM. Cluso99 was probably the closest to being able to do that with his modified interpreter, but I'm not sure it was even on his radar. I recall hippy talking about it at one point (where is he lately?)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

MagIO2
07-16-2009, 09:20 PM
?????

He want's to create a BASIC to SPIN bytecode compiler ... So, the output is a EEPROM-file which of course can include DAT-sections that hold the also compiled PASM code. Of course the BASIC compiler needs some kind of cognew instruction which starts another SPIN bytecode or an assembler section.

Ah ... Ok ... understood what the missunderstanding was:
With INLINE PASM I don't mean to mix PASM and BASIC instructions. Just the same as in SPIN ... a DAT section can contain PASM code. In BASIC -> a function (forced to have only one parameter) can contain only PASM code and the call of this function is compiled to a cognew.

Rayman
07-16-2009, 10:43 PM
If only I had time... I'd like to do a version of Femtobasic that compiles a bit to make it faster... I'd also like to do a Windows program for coding and hooks for debugging...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Bill Henning
07-16-2009, 10:57 PM
My vote is for B - since it should be possible to call Spin objects from that Basic, and Basic functions from Spin.

Adding the special Stamp basic commands would help bring a lot of Stamp users over...


Bean (Hitt Consulting) said...
I was thinking about just messing around with a BASIC compiler for the Propeller. Which to do you think would be most useful:


A) BASIC to Propeller Assembly

Could use to make video/hardware drivers

Limited to 497 assembly instructions





B) BASIC to Spin Tokens

Large programs possible

Same speed as spin code

Easiest to implement compiler





C) BASIC to LMM Assembly

Not as fast as PASM

Large programs possible

Hardest to implement compiler



Which option do you think would be the most useful. And why.



Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com (http://www.mikronauts.com) - my site 6.250MHz custom Crystals for running Propellers at 100MHz (http://mikronauts.com/products/mikronauts-625mhz-crystal/)
Las (http://mikronauts.com/products/las-largos-lmm-assembler/) - Large model assembler for the Propeller Largos (http://mikronauts.com/products/largos/) - a feature full nano operating system for the Propeller
Morpheus & Mem+ (http://mikronauts.com/products/morpheus/) Advanced dual Propeller SBC with XMM and 256 Color VGA
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full

Mike Green
07-16-2009, 11:10 PM
I had started down this path with a Basic compiler for a LMM·called Ouroboros.· I stopped when I ran out of room in a single Spin program.· It could parse and process declarations, simple statements, and generate code (including fixups) for some expression operators and simple statements like IF / THEN and GOTO.· There's a thread somewhere with the last source code.· I meant to start to split the parser and code generator apart into separate phases, but got involved in other projects.

I think a Basic to Spin byte code compiler would be more useful, but I had a better understanding at the time of LMM instructions than Spin byte codes.

By mistake, I included the source code for Ouroboros and Ouroboros1 in the archive I posted for the Winbond/SRAM driver here: http://forums.parallax.com/forums/default.aspx?f=25&m=349616&p=2.




Post Edited (Mike Green) : 7/16/2009 4:21:12 PM GMT

Ken Gracey
07-16-2009, 11:19 PM
Option B is my preference, even though it may not be efficient. It would give a newbie a simple bridge from the BS2 to the Prop, plus the ability to see the Spin code generated by the compiler. This brought many benefits in your SX/B program. Even Peter Vanderzee finally dove into SX/B and we know he's a tough critic to please.

Efficiency, speed and various benchmarks aside, I feel it would be most productive to provide a simple bridge from PBASIC to Spin. I wish all of you could participate in the language debates inside of Parallax. Whether or not we need BASIC for the Prop has been a common discussion. Many customers would benefit, instantly, but their lives could be made easier if they'd just give Spin a try. From my perspective a PropBASIC would be most valuable if it simply improved access.

Keep in mind I haven't worked with Femto yet, and that I've been happy with Spin especially since PST was made available.

Ken Gracey

Oldbitcollector (Jeff)
07-16-2009, 11:26 PM
Option B is the one that makes the most sense..

It would allow for fewer limits in regard to code.

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Visit the: The Propeller Pages (http://www.warrantyvoid.us/tiki-index.php?page=Propeller) @ Warranty Void.

Bean
07-16-2009, 11:32 PM
Thanks for all the input guys.
Just to be clear this is a PC compiler, not an imbedded Propeller compiler.

I know the spin tokens are documented somewhere, but I couldn't find the document. Can anyone direct me to it ?

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...


·

rokicki
07-16-2009, 11:47 PM
Spin bytecodes would *seem* to be a good target.

The only problem is that there's no good way in the Spin bytecode to do a goto,
and normal line-number-based BASIC really wants a goto.

Of course you can hack it (by doing a call and then munging the return
address) but that borders on evil.

Anyway, I'd start by targetting bytecodes, and then after that works reasonably
well add in options for assembly output.

localroger
07-16-2009, 11:56 PM
@rokicki -- there is in fact a Spin bytecode for GOTO; it's code $0C. The Spin compiler just doesn't provide a way to use it directly; it's used to implement Spin control structures like REPEAT and IF though.

I add my vote for structured (not line numbered) BASIC to bytecode; with appropriate Spin functions added to the BASIC language.

rokicki
07-17-2009, 01:35 AM
Oh! How did I miss that! Sorry for the bad information.

WBA Consulting
07-17-2009, 05:19 AM
I am too new at the propeller/SPIN to give a solid vote, but option B would seal the deal on my transition to the propeller from the Basic Stamp. Being able to see the compiled propeller code created from a language I know would be very beneficial. This is how I learned Macro programming in Excel (which is essentially Visual Basic). I would create Macros with the Macro Recorder, go in a change things here and there, and see what happened. Next time around, I would just code what I wanted from the start.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andrew Williams
WBA Consulting
IT / Web / PCB / Audio

heater
07-17-2009, 05:51 AM
Why do this?

Yes I'm sure you can make a BASIC that everyone knows and loves, from their BASIC Stamp or back to their Altair days. But when it comes to doing anything useful, then what?

OK you can ask me about ZiCog etc... I don't know....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

JonnyMac
07-17-2009, 06:02 AM
Exactly; there are a number of projects that any number of us have created that others will question -- the real question is: Why not? And... why judge? It seems like any Propeller oriented project would be helpful -- at least in small part -- to the Propeller user base.

And in the FWIW category, I believe a BASIC compiler would be far cleaner way to to port BASIC Stamp programs than the BS2-type object modules that have been previously submitted.

Code away, Terry!

BradC
07-17-2009, 06:23 AM
Bean (Hitt Consulting) said...

I know the spin tokens are documented somewhere, but I couldn't find the document. Can anyone direct me to it ?


The best reference is the interpreter source.
If you want a hacky way of testing stuff, bst[c] has an extra command that allows you to inject raw bytecode into SPIN methods
Bytecode($01,$02,$03) and so on. It's easier than building binaries for simple tests.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

QuattroRS4
07-17-2009, 06:42 AM
Bean said...
I was thinking about just messing around with a BASIC compiler for the Propeller.


Initially I thought of opting for option B ... then I thought why? I'm not sure why - 'Just Learn Spin it's not that difficult' I then thought 'Hey - A Basic compiler for LMM is the way to go' - just read Mike Greens post and that killed that .. Is there a reason that you have started down this path ?

Regards,
John

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

'Those who can, do.Those who can’t, teach.'
'Convince a man against his will, he's of the same opinion still.'

·

RossH
07-17-2009, 08:43 AM
@Bean,

Definitely go with (B). The only problem you have here is floating point - but if you're willing to live without that, this would be your best option.

As to the other options ...

Option (A) is too limited as to code size to be much more than a gimmick - it would be hard to get a compiler optimized enough to write useful drivers.

Option (C) Is already available. Just use b2c (or another Basic to C translator - there are several available) with Catalina. Okay, I haven't actually tried this - but I think you'll find this would give you a working basic compiler for the Prop in far less time than it would take to write one.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Microcontrolled
07-17-2009, 09:21 AM
I vote A, but because of space I vote B

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.


If it's not Parallax then don't even bother. :-)
·

Mini-Din/PS2 connectors are for sale! 5 for $1! PM me if you wish to make an order.
Cheap·shipping unless specified!··········150 left!!··

Peter Nachtwey
07-17-2009, 09:52 AM
I would go for A but with a twist. I can't see where basic is any better than SPIN. If you want interpreted code use SPIN as it is. I would not even consider making a basic to assembly compiler. It would be yet another language/compiler/tool to learn.
I think the best answer is to write a SPIN to PASM compiler or better yet, SPIN code to machine code compiler. This way one can write ALL their code in SPIN only and chose between speed and memory. One language, one code base, speed or memory efficient, your choice.

Ken Gracey
07-17-2009, 09:30 PM
I agree that BASIC is no better than Spin for the Propeller, particularly if some of the BASIC Stamp's architecture-specific use of BASIC show their limits in the Propeller. I'm guessing that many comments from people above are from those who came into Parallax for the Propeller. Most of us on this forum don't have a 15-year BASIC Stamp history behind us.

PropBASIC is of interest when you look at our company's history and customer base. It's reasonable to say that Parallax was built upon the BASIC Stamp with many useful educational programs, creative people inside Parallax, accessories, and books that go with that product. These BASIC Stamp customers would benefit tremendously to have some kind of bridge between PBASIC to at least try the Propeller. Even if a PropBASIC compiler executed Spin code the same speed as a BASIC Stamp 2 ran PBASIC and made only minimal use of concurrent processing it would be a tremendous boost for millions of BASIC Stamp developers. They simply need any barrier (perceived, real, architectural or hardware) reduced enough to step in and run a few programs in the Propeller from their favorite Stamps in Class book. That's all. It isn't necessary to have a full-blown PropBASIC environment. It needn't even use PBASIC structures, commands, etc.

As BASIC Stamp customers continue to gain experience with our products it would be a shame to loose them to "more capable' Stamp-like devices instead of showing them the Propeller. I can hear many of you now say "but Spin is so easy!". If you've been raised on a single programming language and you've made your way successfully with a business and hobby around that language/product it can be difficult to justify forward motion. . . especially if all is going well already.

One other solution is a side-by-side tutorial comparing Spin and PBASIC, showing the same program in both languages. This approach would only be useful for a limited number of examples until the architectures diverged in the second chapter.

The concept of a BASIC compiler for the Propeller has been discussed a whole bunch at Parallax. We know it's a year-long project for us to undertake, and I've encouraged that we don't do it internally. While it helps our BASIC Stamp user try the Propeller as I've advocated above, it redirects our internal resources away from engineering efforts that we need to apply to make the Propeller sell in volume. Parallax's future business with the Propeller must include commercial applications produced in higher volume, and the efforts we need to apply towards those customers command the attention of our internal resource base. This includes specific customer support, improved datasheets and objects, IDE support, and Propeller 2. Once we take care of those engineering efforts we have no time to do anything as Bean has proposed.

It is our hope that such a compiler could be produced by our customers or friends. Just as Bean has done with SX/B and the SX-Key IDE, we could envision a PropBASIC being integrated with our Propeller IDE. I believe it is a matter of time before this happens. The longer we delay the internal efforts the more room exists for us to partner with somebody outside of Parallax.

Ken Gracey
Parallax Inc.

P.S. to BASIC Stamp users: we have new products in the plans for you over the next year. This includes WiFi BOE hardware for wireless programming/internet connectivity, renewable energy Stamps in Class programs, etc. The BASIC Stamp product line will continue to improve.

Cluso99
07-17-2009, 10:18 PM
Option B because as Ken has said, it provides the simplest way for Stamp enthusiasts to move to the prop.

Maybe the compiler could just convert the PBasic to Spin and then feed to the normal spin compilers. Not sure if this is feasible or not. It would provide a good feature for learning spin, but it would add another step.

As for embedded pasm, this "could" be done using an LMM model...
HOWEVER, I see 2 problems. One is the obvious jump problem, and the other is where are the variables? There is no room in the standard Spin Interpreter. I have some space in my faster version and I can (have already done it for for debugging in my interpreter) place the LMM interpreter in the shaddow ram for zero footprint. The interpreter could be extended to do floating point, either by LMM or overlays. My spin interpreter was giving 20-25% speed improvement before I optimised a couple of routines and broke it. Been busy with other things since.

BTW - I would not use PBasic now, although when I first started it would have helped me. I was not a Stamp user.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Ken Gracey
07-17-2009, 10:30 PM
@Cluso99: You came in as a Prop user, too, so you would also not be a user of a PropBASIC compiler as you noted. It would be really interesting to ask this question on the BASIC Stamp forum. It helps to define the specific audience and need before starting such a project. Though floating point could be a great addition to PropBASIC, on the other hand it might be the reason for somebody to finally take the leap from PropBASIC to Spin/ASM after getting beyond the initial "hey, I CAN program this thing after all!" excitement. The Float32 library is easy to use in Spin and I cringe at trying to see some of this stuff accomplished in a PropBASIC compiler. This project has such daunting potential that it could be impossible to start if scoped out to the satisfaction of an engineer vs. the needs of a seasoned BASIC developer who just needs to try something new.

Once a simple PropBASIC compiler is available, we'd likely see the King of Stamps (Jon McPhalen) make many simple requests to improve the tool. I'm suggesting that we need to have some kind of Option B solution just to get started. Just like BST, a starting point allows for much improvement.

Very excited about this possibility,

Ken Gracey
Parallax Inc.

hippy
07-17-2009, 11:06 PM
BradC said...
Nobody has come up with a modified interpreter that will allow you to inline PASM. Cluso99 was probably the closest to being able to do that with his modified interpreter, but I'm not sure it was even on his radar. I recall hippy talking about it at one point (where is he lately?)


Still here, still lurking, still not active in the Propeller world at the moment.

A modified Spin Interpreter can run LMM PASM or even load in and execute native PASM. My idea was to subvert CogNew/CogInit with start address of $0000..$000F ( which wouldn't make sense for real Spin ) as an 'escape' to non-standard and the argument the adress of what to run ( or sumething like that ).

There's also option D ... convert Basic source to Spin source.

And option E ... code up a Basic Stamp interpreter so the Propeller looks to the end user like a Basic Stamp with extra goodies.

jazzed
07-17-2009, 11:10 PM
I was just wondering a few minutes ago how long it would take hippy to finish one of these year long projects given proper motivation :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

mpark
07-18-2009, 12:06 AM
I thought Bean was already working on option E. Focus, Bean, focus!

rokicki
07-18-2009, 12:10 AM
That's an idea that's intriguing---allow LMM-style assembly callouts from Spin! Someone should push on this idea.

Rayman
07-18-2009, 01:37 AM
Personally, I think compiling to SPIN would be great, but overkill... Besides, I think the main thing people would be interested in is debugging their code from a Windows App with breakpoints and watches and so forth... I'm not sure speed would be a driving force. But, I guess it depends on the target audience. You'll never get me going back to BASIC!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Bean
07-18-2009, 03:07 AM
mpark said...
I thought Bean was already working on option E. Focus, Bean, focus!
Ha ha, yeah "focus" that is downfall.

I worked on this for awhile and made some headway, but the PBASIC tokens are really screwy to try to decode. Lot's of "tricks" were used to get the most code in the smallest number of eeprom bits. But it causes all kinds of headaches trying to decode it back.

Right now I'm thinking that a PBASIC to spin code (not tokens) would be the best option. The biggest concern is the lack of a GOTO in spin. I'm not sure how that could be worked around. If anyone has any ideas, I'm all ears...

Bean.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...


·

John Abshier
07-18-2009, 04:11 AM
I looked at some PBASIC programs. Most use goto. Note there are implicit gotos (IF (iPins = 0) THEN Loop). It appears that the usage of goto could be replaced by loops (repeat in Spin) and by if/elseif/else constructs. I don't know how hard that would be to do automatically. Easy for me, since I am not going to do it myself! Is the goal to run all PBASIC programs or to let people write PBASIC programs for the Propeller? I don't think a goto is required in PBASIC 2.5. Prhaps a PropBASIC with no goto? I haven't liked goto since I spent a couple of hours pouring over a FORTRAN paper listing, trying to find the label corresponding to a goto. I didn't think to look at the line immediately after the line with the goto. It would be interesting to characterize what is hard for PBASIC programers to do in Spin. PBASIC has many functions that are easier to use than equivalents in Spind, but are also more limited The Propeller/Spin have, with people I have met, an undeserved reputation for being hard to use. I guess that people think that if it is this powerful, it must be hard. I find it easier than AVRs with GCC.

John Abshier

Cluso99
07-18-2009, 04:28 AM
Ken: Yes, I think you are correct - ask on the stamp forum. I guess that is why I like the idea of a precompiler because it would then show how the same code could be done with spin and may result in the user moving to spin more easily.

Hippy: Yes inline pasm run in LMM is easy - only need the compiler to handle the jumps. LMM is "actually" running in my interpreter in shaddow ram to debug the interpreter. So all it takes is a call to the LMM routine and the LMM compiled code to reside in hub http://forums.parallax.com/images/smilies/smile.gif

As for the actual goto implementation, I have no idea as to how this would work, but it could be done provided the compiler checked that the goto was within the current routine. Jumps outside the current routine would be a disaster. I am sure there was a goto type bytecode.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Ariba
07-18-2009, 04:37 AM
Bean (Hitt Consulting) said...

Right now I'm thinking that a PBASIC to spin code (not tokens) would be the best option. The biggest concern is the lack of a GOTO in spin. I'm not sure how that could be worked around. If anyone has any ideas, I'm all ears...



A possible solution is in this thread, just add this 2 posts together:


BradC said...

If you want a hacky way of testing stuff, bst[c] has an extra command that allows you to inject raw bytecode into SPIN methods
Bytecode($01,$02,$03) and so on. It's easier than building binaries for simple tests.



localroger said...
...there is in fact a Spin bytecode for GOTO; it's code $0C. The Spin compiler just doesn't provide a way to use it directly; it's used to implement Spin control structures like REPEAT and IF though.



Andy

mpark
07-18-2009, 05:23 AM
The hard part is figuring out the offset for the GOTO. And by hard, I'm thinking insurmountable—but I'd love to be proven wrong.

Bean
07-18-2009, 05:32 AM
Right now I'm working on a document that details how to convert PBASIC structures to SPIN.
I'm assuming that this hasn't already been written. At least I couldn't find it.
Let me know if you know of one...

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...


·

Bill Chennault
07-18-2009, 06:18 AM
Bean and Ken and All--

Like I said about two years ago, there are some excellent reasons why some version of BASIC should be available for the Propeller. BASICALLY, one of them is the fact that it won't boot DOS. In the old days, booting DOS was like running BASIC today. If it would not "boot DOS" (or run BASIC for the last umpteen years), it was almost pre-ordained to failure as a consumer computer product.

No matter how good the Propeller is and no matter how clever the Spin or assembler code is written by the cleverest of the authors--and I KNOW there are some very clever ones on this forum--without BASIC the Propeller has a highly select audience far, far narrower than the mass-programming audience that cuts BASIC code for products in their sleep.

If the Propeller were open to the masses and more importantly, their minds which number in the MILLIONS, not the few hundred that cut Spin or PASM, then the Propeller might see daylight as a commercial product due to its HUGE advantages as a microcontroller.

I applaud this proto-effort and hope it turns into a true effort resulting in a real product which will, in turn, introduce a great microcontroller to a huge amount of people. Heck, there would probably be more people that would buy the thing just to try it with BASIC than the entire sales of the Propeller to date.

At least, I hope so and that's my story and I'm sticking to it.

--Bill



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.

BradC
07-18-2009, 07:56 AM
mpark said...
The hard part is figuring out the offset for the GOTO. And by hard, I'm thinking insurmountable—but I'd love to be proven wrong.


I'm pretty sure it can be done. It all depends how the compiler works I guess.

bstc compiles SPIN to an interim set of assembler (spin bytecode) tokens with labels and the assembler figures out the addresses and offsets as it shuffles things around and optimises them. Inserting a label for a goto target is a piece of cake. The hardest part with SPIN is ensuring you don't jump into or out of a construct that has a large stack presence that needs to be accounted for, and even that is not impossible (well, jumping into it is, but not out of).

The main issue for bringing over stamp users is the built in routines (pulsout, serin/out and the like) and I'm pretty sure that could be reasonably handled with a helper cog.

Personally I *love* the idea of a stamp emulator that can run unmodified stamp bytecode, but a compiler is a close second I guess.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

waltc
07-18-2009, 07:59 AM
The Prop needs a decent BASIC compiler, at least then the Prop would be easier to access for those folks weaned on the BS2 and those who use BASIC on the AVR and PIC.

It would also be a good alternative to C and SPIN.

mpark
07-18-2009, 08:17 AM
Brad, my comment was in the context of a BASIC-to-Spin (source, not bytecode) translator. Of course, we're already talking non-standard Spin, using BST's bytecode directive to inject GOTOs... Hmmm... maybe you could add an explicit label feature to BST...

BradC
07-18-2009, 08:27 AM
mpark said...
Brad, my comment was in the context of a BASIC-to-Spin (source, not bytecode) translator.


My apologies.. yes, without an explicit label feature that would be most ugly and quite likely impossible.

I thought about adding a goto and label feature. That would work quite adequately within a spin function, but it would allow such braindamaged programming that it would remove the advantages SPIN has in a language that enforces good practice (pascal allows goto also but it's pretty frowned upon) :)

I've always thought a BASIC to SPIN source translator would be quite ugly at best. The Bytecode lends itself to abuse that would suit a BASIC compiler, but I'm not sure the SPIN source constructs translate adequately to BASIC.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

jazzed
07-18-2009, 09:04 AM
The only time I ever use goto is for speed and/or a single exit point as is often the case in Linux C device drivers (academics and ego-maniacal-testosterone-driven programmers roll eyes here :).

Such a feature might find similar use in Spin (I know, abort helps). I probably won't spend much time looking at code that uses goto where better "language features" could be applied. Alas, if there are truly millions of BASIC programmers out there, having a little goto wouldn't hurt in providing therapy.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

localroger
07-18-2009, 09:21 AM
There's a huge problem with translating BASIC to Spin, which is the lack of Spin GOTO.· It is almost impossible to do anything in Stamp BASIC without using GOTO, and expecting an automatic translator to figure out how to turn your spaghetti code into REPEAT loops is not really realistic.

BASIC to Spin bytecode should be very do-able, though.· Spin bytecode is actually very FORTH-like, and it will take some compiling to get BASIC into bytecode form.· I've done this myself for a couple of projects where I built my own bytecode interpreter, though, and on a PC it's no big deal.

I think possibly the most practical target would be an alternate PropTool that speaks StampBASIC, using pre-defined PASM routines in helper cogs to implement the stampy things like pulsin, perhaps even without the ability to write your own PASM code.· But write StampBASIC-like code, hit F11, have it go into your propeller which has no idea it didn't start as Spin, and the prop does what you expect.· When the limitations get too restrictive pick up the manual and learn Spin and PASM.

waltc
07-18-2009, 09:50 AM
There's no law mandating Goto as a requirement in Basic. It would be better off without it.

Look, why keep a Basic Compiler pbasic compatible anyways, since Pbasic was always a quick and dirty language designed to fit a micro with almost no ram. Besides it was hardly anyone's idea of a good programming language.

So move away from Pbasic and towards a more structured Basic.

Cluso99
07-18-2009, 11:24 AM
The more I think about this, the more I think Brad is right. A stamp emulator is the way to go. I think this is harder but would be way better in the long run. Comments please?????

It does not matter that only a few helper cogs are used for the serin, etc routines. It's a requirement to allow the Stamp group to migrate to the prop with ease. Then they can opt into using spin or pasm at their own pace, or remain on the stamp emulation, their choice.

GOTO is a "reality" that MUST be included if the objective is to make it simple to move platforms. It does not matter how much·WE hate it.

We all have nice things running like SD cards and FAT16/32, external memory, multiple props, etc. That is not relevant for these people yet - it is just the lure that these are available. It is the reason they may later convert to spin and pasm, but for now, they require easy transition.

This therefore leads me to think (and remember I have never used the stamp, pic or avr, so take that into account with weighting·my opinion) that what is required is perhaps twofold (because different people will do them)...

1. Basic to LMM pasm or some form of intermediate bytecode and interpreter. Must run existing Stamp Basic no slower that the Stamp.

2. A Stamp Emulator like ZiCog/MoCog.

We are really getting some great input from the guys that can do these things, but alas, not much from the actual users, who are of course on the Stamp Forum. Ken, your updated thoughts???

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

localroger
07-19-2009, 03:04 AM
StampBASIC isn't a bad language, especially considering the resources available for it; it's structured, allows for meaningful procedure, label and var names, and supports a very useful range of built-in functions. But in order to do anything useful when you have only a few hundred tokens for program and literally just a few bytes of RAM, you have to take a lot of shortcuts. Stamp legacy code is going to use those shortcuts so any bridge from the Stamps to the Prop will have to implement them.

Hub RAM is going to look HUGE to a StampBASIC programmer. But he's also used to being able to say PULSIN and measure the width of a pulse without any other work, SERIN to receive the next incoming byte of serial data on any I/O pin at any baud rate normal or inverted, PWM to charge a capacitor to any desired voltage on any I/O pin. He doesn't have to figure out how to do that in finer code or hunt down an object; it's just there, and most of those functions are there in every iteration since the BS1. (Later stamps also have things like X10 and I2C functionality, which need to be available if you want to get those projects ported.) Of course he's also used to the CPU locking up for any other work when he does any of those things, and that's why the Prop's 7 extra cogs are going to be so seductive http://forums.parallax.com/images/smilies/smile.gif The Stamp Editor also has an automatic debug object which pops up after a download if there are any DEBUG statements in the program, and with no configuration or setup uses the programming link to return messages to the programmer.

I think a good Stamp emulator for the Prop would be a great thing for seducing the Stamp kiddies to the more powerful platform. It should have its own IDE similar to the Stamp Editor which transparently and automatically programs the Prop with the user's program and, whatever emulation infrastructure is needed, so that it acts like a Stamp on major steroids. Commands should work by default as they do in Stampworld, inline and locking up the CPU, but with new versions available that take advantage of other cogs to allow concurrent operations. You could also support the keyboard, video, maybe even mouse via functions to read X and Y. But you shouldn't have to compile in objects to do that; it should be a simple option that you enable within the Pseudo Stamp Tool. Implement enough functions to make the typical Stamp programmer drool, then when he hits the limit because the system can't be optimized, refer him to the Spin manual and Obex.

One way to handle the more advanced functions would be to compile things like pulsin to calls to Spin objects actually written in Spin (and transparently added to the program at download). These could in turn issue commands to other cogs, wait or not wait for results, etc. Basic math and data storage could be translated pretty seamlessly into Spin bytecode. And Stamps don't really do much more than that. Speed is not a big deal; Stamps load their tokens directly from serial EEPROMs so in addition to having HUGE RAM, the Prop Stamp emulator is also going to run like blazes compared to a real Stamp. Heck, you could probably write the entire emulator interpreter in Spin and it would STILL run circles around a real Stamp.

And I have actually used plenty of Stamps through the years, mostly for industrial controls. Sometimes what you need is something quick, dirty, and reliable for a simple function, and you want it to Just Work. I could even see using something like this myself occasionally when I need something simple and quick and I don't feel like figuring out how to pass pin parameters to some object I don't use very often.

sam_sam_sam
07-19-2009, 03:45 AM
Ken Gracey

PropBASIC is of interest when you look at our company's history and customer base. It's reasonable to say that Parallax was built upon the BASIC Stamp with many useful educational programs, creative people inside Parallax, accessories, and books that go with that product.

I started with the BS2 and now trying the SX Chip


·These BASIC Stamp customers would benefit tremendously to have some kind of bridge between PBASIC to at least try the Propeller. Even if a PropBASIC compiler executed Spin code the same speed as a BASIC Stamp 2 ran PBASIC and made only minimal use of concurrent processing it would be a tremendous boost for millions of BASIC Stamp developers.


For me it· would help tremendously to have some kind of bridge between PBASIC to at least try the Propeller


·They simply need any barrier (perceived, real, architectural or hardware) reduced enough to step in and run a few programs in the Propeller from their favorite Stamps in Class book. That's all. It isn't necessary to have a full-blown PropBASIC environment. It needn't even use PBASIC structures, commands, etc.



I have to agree with you on this





On another note

I know that it cost money and time to do·what you are talking about and you have to do what will make your company·the most money and keep

your customer happy·when it all said and done and that the way it should be


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
··Thanks for any·http://forums.parallax.com/images/smilies/idea.gif·that you may have and all of your time finding them http://forums.parallax.com/images/smilies/smile.gif

·
·
·
·
Sam

Post Edited (sam_sam_sam) : 7/18/2009 8:55:20 PM GMT

waltc
07-19-2009, 04:38 AM
cluso wrote:
The more I think about this, the more I think Brad is right. A stamp emulator is the way to go. I think this is harder but would be way better in the long run. Comments please?????

Bad idea because that takes away all the performance gains that one gets by going over to the Prop.

Look a straight forward Basic compiler(LMM pasm) with all the Pbasic goodies would be a good starting point IOW a decent language that can serve not only BS2 users but others who like to use Basic and don't want to mess with Spin such as myself.

localroger
07-19-2009, 04:49 AM
waltc -- I have to disagree. Implementing a fixed simulator doesn't take away ALL the performance gains, as it will still run circles around a regular PIC-based stamp. For a bridge from Stamps to the Prop you need something that implements the built-in hardware I/O functions of the Stamp in a way that is as simple and convenient as it is on the Stamp. And that means the opposite of versatility and performance; sometimes it's WORTH trading convenience for those things. When you outgrow the bridge platform you can always pick up the Spin manual to go to the next level.

sam_sam_sam
07-19-2009, 04:55 AM
·localroger

For a bridge from Stamps to the Prop you need something that implements the built-in hardware I/O functions of the Stamp in a way that is as simple and convenient as it is on the Stamp.

I· have to agree with on this one

·And that means the opposite of versatility and performance; sometimes it's WORTH trading convenience for those things. When you outgrow the bridge platform you can always pick up the Spin manual to go to the next level.

One of the nice thing about the SX ide is that you can write your code in Pbasic and see what it would look like in Assembly· Language·that

is very helpful

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
··Thanks for any·http://forums.parallax.com/images/smilies/idea.gif·that you may have and all of your time finding them http://forums.parallax.com/images/smilies/smile.gif

·
·
·
·
Sam

Post Edited (sam_sam_sam) : 7/18/2009 10:07:17 PM GMT

Dr_Acula
07-19-2009, 08:38 PM
I vote B). And with great excitement too as this could be a real "killer app". Or at least make the prop attractive to Basic Stamp and Picaxe users. Plus the generation who started programming with:

10 PRINT "Hello World"
20 GOTO 10

And having learnt that, then had to unlearn it as GOTO is not considered Structured.

I guess this could open a bit of a pandora's box, but GOTO is not needed at all in Basic. vb.net doesn't need it and I've been using a dialect called Sbasic written in the early 1980s that uses a structure that makes GOTO completely unneccessary. Indeed Sbasic probably has more in common with Spin than with the Mbasic example above.

Line numbers also are not needed.

So - which dialect of Basic? Certainly a hybrid of Basic Stamp and Picaxe Basic. Plus borrow some bits of vb.net, eg Endif.

There are some C structures that are handy too. C uses { and }, which in Sbasic translate to Begin and End. This wraps up bits of code so they can go inside loops (repeat..until or while...wend or do...loop). Much as Spin has the dropdown lines that link If statements.

And one needs a system for local and global variables. In picaxe basic, every variable is global, as with Mbasic. With vb.net, most variables are locally declared in each procedure/function, and sometimes it makes sense to have a few global variables.

This might be hard to say on a Prop forum, but I still find it hard to think in Spin. I tend to think in Basic and then convert to Spin. So I've thought about some of the steps needed to make a Basic compiler for the Prop. It is, shall we say, hard, but not impossible.

An IDE on a PC makes sense as a compiler. I spent a lot of time coding in Mbasic when I was younger and remembered it fondly. Then I went back recently and tried to write some code. The reality is that it is slow and the editor is tedious and one misses the modern touches like color coding for instructions and comments etc. So I wrote an IDE for Sbasic for CP/M. It is color coded (not that hard, just search libraries of instructions eg if you find a ' or a rem, make that text green till the end of the line). It shells out to the Altair SIMH to do the compiling (only a few seconds) vs about 2 minutes on a real board. And then downloads quickly.

The key would be to get the compiles to be similar speed to Spin compile/downloads, and that ought to be entirely possible.

I could make this a really long post by listing all the Basic keywords and Spin equivalents. Suffice to say that there is much that can be translated one to one. Spin declares variables at the beginning. So should Basic. Spin links in Objects. Well, those objects could be Spin or Basic-translated-to-spin. Spin declares constants. So should Basic.

Then there is the code body. Well, this may not be so hard. Spin has
If variable1 == variable2
variable3:=variable4

(I hope I got that right!)

which translates to
If variable1 = variable2 Then
variable3 = variable4
Endif

Just minor changes with the double equals and the colon.

You can put auto tabbing in as vb.net does as part of the IDE so it helps encourage indented code (much as Spin does).

So the main structure could be built fairly quickly. And then there is something very powerful that could be borrowed from Sbasic, and that is the ability to write new functions and procedures that you can use in the same way as inbuilt procedures. Eg
string1=mid$(string2,5,3)

Mid$ is a standard Basic keyword, but sbasic allows the writing of new functions and procedures that you can use in the same way. So if you don't like the $ you could write your own function mid( instead of mid$( And even better, that function could use assembly and basic mixed together. So the language can grow incrementally rather than being a daunting task. I've added some to sbasic that I liked in vb.net, eg Trim and Ucase and some file handling. eg



rem Converts string to upper case
function ucase(mystring=string) = string
var i=integer
var outstring=string
var ch=byte
outstring=""
for i=1 to len(mystring)
begin
ch=mid(mystring,i,1)
if ch>='a' and ch<='z' then ch=ch-32
outstring=outstring+chr(ch)
end
next i
end=outstring



I've just finished writing all the Basic string functions and a lot of the math functions in Z80 assembly, so I can see there are many ways to solve this problem.

Looking at many Basic keywords, there seem to be Spin equivalents that are just slightly different. Of course, slightly might just be a colon, but in one language that might be necessary and in another it is a syntax error. So - the IDE might just start off with a simple rich text box (as does my Sbasic IDE which is written in vb.net), and hitting a compile button runs through each line and converts it to the text that Spin needs. I think that would involve things like converting tabs to a certain number of spaces and splitting Repeat loops into several lines. Then read that text back into the Spin IDE to put in all those little linking lines.

Even cooler would be the ability to see both programs side by side. That could be the key to making Spin more popular...

Post Edited (Dr_Acula (James Moxham)) : 7/19/2009 1:49:15 PM GMT

WNed
07-19-2009, 11:26 PM
@James - As interesting and enlightening as your post is, It seems you may have missed the point that (unless I missed something on Page 2) the basic compiler proposed will generate byte code directly, not do a Basic-to-Spin translation. I suppose you may mean that very thing, but are saying "Spin" in reference to byte-codes. If so, sorry, I'll sit down and shut up now...
In General - I like the structure/syntax combination of plain old VB. It has the familiarity of syntax that I should think any Basic programmer can embrace, with a fairly intuitive event/function structure that seems a natural to implement for a controller. When one is comfortable with the creation and use of functions, it's easy to forget that GoTo ever existed.

Ned

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno

Post Edited (WNed) : 7/19/2009 7:38:08 PM GMT

Lab Rat
07-20-2009, 02:33 AM
rokicki said...
Of course you can hack it (by doing a call and then munging the return
address) but that borders on evil.

sounds like fun if it is evil lol i am a basic user if i could get my grubby paws on a prop stick i would try to learn it in fact my next parallax purchase will be a starter kit with a prop in it


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax posesses power beyond belief.

Believe in it.

Dr_Acula
07-20-2009, 07:11 AM
Yes, Wned, I missed that. Actually any sort of Basic compiler would be fantastic. As for syntax, a simplfied version of VB could be a good starting point. Another idea - I wonder if it is possible to make some of the coding easy for people to collaborate so people can add their favourite instructions and then share them? Much the way the Spin object library works? Thanks ++ to Bean for offering this!

Cluso99
07-20-2009, 11:58 AM
The target audience is the Stamp users. WIth that in mind, the main objective should be compatibility. So, it needs to run Stamp Basic, with all its terrible goto's etc.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

LEDboy
08-02-2009, 01:06 PM
I will pay for that program if you make it!!!· I can read the propeller book all day and just when I think I have it figured out...its back to the book and scratching my head again...I love the proppeller when I can get it to do what I want it to...if there was a book out there like the StampWorks book I would be the first in line to buy it...I found that I can understand code if I have something to "bump" it up against....thats why I think this program would be so great for the people that want to make the jump from the BS2 to the Propeller...I can write the program in a PBasic that I understand and then look at the same program in SPIN and see what does what in the SPIN program.http://forums.parallax.com/images/smilies/hop.gif

WBA Consulting
08-03-2009, 03:21 PM
Even though I am still waiting for the beta release, I am already digging into Propeller usage. One thing I recently stumbled upon, that doesn't seem to be communicated to Prop newbies enough, is the SPIN tutorials that are accessible in the Prop IDE help files. The plain English explanations are excellent and have already cleared some confusion from the propeller manual.

On a side note, an idea for a nickname for the compiler is B3 (for Bean's Bernoulli Basic) or Bernoulli Basic. Bernoulli's principle can be used to model the dynamics of a propeller, so I think that's a good analogy for something that reduces the available performance of the propeller processor yet is still a working propeller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andrew Williams
WBA Consulting
IT / Web / PCB / Audio

Bean
08-03-2009, 06:46 PM
The more I think about it, I think the best bet is....

to follow Chip's original idea. Write a PBASIC interpreter in LMM (instead of spin as I was doing earlier). This would give a big speed improvement, and still have lots of code space for all the high-level commands.

However, because of the EOL status of the SX, I am now required to re-design several products at my work (real job). So I'll be quite busy for awhile, and I don't think I'll have much spare time to devote to this project.

If ANYONE else wants to work on a Propeller BASIC compiler, please do. Perhaps we can colaborate in the future.

Bean.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...


·

Cluso99
08-03-2009, 06:54 PM
That would have to be "3B" like 3M http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

StressLess
08-04-2009, 07:44 AM
With the End of Life announcement for the SX I think a Basic compiler for the Propeller has taken on a new significance!

In my case I had decided on the SX for a new product being developed and had only last week bought the SX development kit only to have the EOL announcement posted the very next day after the kit arrived http://forums.parallax.com/images/smilies/shocked.gif !! I contacted the Parallax sales department and they were kind enough to swap out the SX kit for a Propeller kit (though overkill, the Propeller would certainly be able to handle my application) http://forums.parallax.com/images/smilies/smile.gif .

Among the reasons I had chosen the SX was the ability to use Basic for programming and the excellent developer's kit and support from Parallax. I had originally learned BASIC sitting in the store window of a Radio Shack on a TRS-80 Level I system and have used it in various incarnations over the years. Last time I did embedded control design was with the Zilog Z-8 about 6 months after the chip was first introduced and had to work in assembly. My current need for a microcontroller is more complex than that Z-8 project was and I would like to work in a high level language that I'm familiar with rather than assembly (much less a new assembly language). The problem with having to learn a· new language becomes whether I'm troubleshooting ME or the·code I'm writing!·http://forums.parallax.com/images/smilies/smurf.gif

Version 2 of SX/B·added some pretty nice features, I would like to see a Propeller Basic based off this version of Basic·rather than Stamp Basic. I think that would be a good place to start, and then expand it later based on the Propeller's capabilities.

If Propeller Basic is intended to be only a learning tool and not a serious development tool then compiling to Spin would make some sense, but if it's intended to be a serious development tool (like SX/B) then compiling to Spin might not work out as well as compiling to LMM.

James

PS- my generation never had to "unlearn" GOTO, computer languages eventually evolved to render the GOTO construct as unnecessary (just like nobody had to "unlearn" how to ride a horse when Ford introduced the Model T!). Would I use·a GOTO·again if needed? I not only would·but I have, it's foolish to ignore ANY tool in your toolbox that gets the job done and makes the customer happy...


Post Edited (StressLess) : 8/4/2009 5:42:47 AM GMT

JonnyMac
08-04-2009, 09:04 AM
Like many, I'm a long-time BASIC programmer and it took a few days for me to bend to the Propeller way. Once I did I found it very easy and I'm having fun. Don't get me wrong, I love the SX and the EOL affects EFX-TEK pretty severely; all of our accessory products have SX processors and I'm writing new product code right this second. I joked with my partner today that I wish we had put a Propeller in the circuit; the EOL becomes a non-issue and the integration of VPs is WAY easier.

If you've done any Assembly programming then PASM is pretty easy to pick up and I find myself porting SX modules all the time. In fact, when I have to write anything in SX Assembly (admittedly, not a lot) I sometimes wish it was as easy as PASM.

BTW... the whole GOTO issue makes me laugh, especially at the anti-GOTO snobs. Internally...


Main:
' do something
GOTO Main



is exactly the same as:


pub main
do
' something
loop



GOTO (which assembles to jmp) is cleaner to use when the "something" section is substantial.

Peter Verkaik
08-05-2009, 08:09 AM
From a BS view, there is only one stack.
Treat a GOTO as a parameterless CALL and remove the return address
from the stack (eg. increase stackpointer) in case of GOTO.
One way·to do it is to pass a·hidden·value to·each subroutine
(a GOTO target is an assumed subroutine entry) that is added to the stackpointer.
The hidden value is 0 for·a genuine CALL.

regards peter

Bean
08-05-2009, 09:29 AM
I don't think spin supports labels at all does it ???

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...


·

Bill Henning
08-05-2009, 09:36 AM
It does...


Bean (Hitt Consulting) said...
I don't think spin supports labels at all does it ???

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+ (http://mikronauts.com/products/morpheus/) Advanced dual Propeller SBC with XMM and 256 Color VGA - PCB, kit, A&T available NOW!
www.mikronauts.com (http://www.mikronauts.com) - my site 6.250MHz custom Crystals for running Propellers at 100MHz (http://mikronauts.com/products/mikronauts-625mhz-crystal/)
Las (http://mikronauts.com/products/las-largos-lmm-assembler/) - Large model assembler for the Propeller Largos (http://mikronauts.com/products/largos/) - a feature full nano operating system for the Propeller

JonnyMac
08-05-2009, 09:41 AM
Really, labels in Spin? -- that is, other than method names? Seems odd as there is no GOTO mechanism in Spin to route code to a label. PASM is another matter; with jmp labels are required.

Bill Henning
08-05-2009, 09:47 AM
Sorry!

My bad, for some reason I thought Bean was taking about PBASIC. I should have read higher in the thread!


JonnyMac said...
Really, labels in Spin? -- that is, other than method names? Seems odd as there is no GOTO mechanism in Spin to route code to a label. PASM is another matter; with jmp labels are required.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+ (http://mikronauts.com/products/morpheus/) Advanced dual Propeller SBC with XMM and 256 Color VGA - PCB, kit, A&T available NOW!
www.mikronauts.com (http://www.mikronauts.com) - my site 6.250MHz custom Crystals for running Propellers at 100MHz (http://mikronauts.com/products/mikronauts-625mhz-crystal/)
Las (http://mikronauts.com/products/las-largos-lmm-assembler/) - Large model assembler for the Propeller Largos (http://mikronauts.com/products/largos/) - a feature full nano operating system for the Propeller

Peter Verkaik
08-05-2009, 10:04 AM
No labels in spin.
If I am not mistaken, each method has a table entry.
My idea is to turn ALL pbasic labels into methods.

All these methods start with the statement
· SP := SP + SPadjust
where SPadjust = 0 for a GOSUB, and 4 for GOTO (4 because stack is long aligned)
SPadjust is a system variable declared by the compiler

So a GOSUB NAME translates to

SPadjust := 0
NAME

and GOTO NAME translates to

SPadjust := 4
NAME

Don't insert RETURN tokens until a pbasic RETURN is encountered


regards peter

Peter Verkaik
08-05-2009, 10:38 AM
Simpler,

If all pbasic labels are turned into methods,

GOSUB NAME translates into
NAME

GOTO NAME translates into
NAME
RETURN

Don't insert RETURN tokens until a pbasic RETURN is encountered

Edit:
This won't work.
For example
MAIN:
· GOTO MAIN
would translate into
PUB MAIN
· MAIN
· RETURN
but results in stack overflow
Using the SPadjust
PUB MAIN
· SP := SP+SPadjust
· SPadjust := 4
· MAIN· 'implied SP := SP-4 due to pushed return address
That works.

regards peter

Post Edited (Peter Verkaik) : 8/5/2009 7:09:24 AM GMT

jazzed
08-05-2009, 10:41 AM
If you run a PBASIC interpreter in a COG instead of using SPIN, you can save a COG by relaunching in COG 0.
Of course if you have no extensions to PBASIC to allow using such power, that won't matter much.

BTW, The labels are there; they are just invisible :)

I suggest looking at the output listing of mpark or BradC's compilers. You'll be in GOTO heaven there.
For a really good spaghetti code example, have a look at the list output of the CASE based Tv_Text.spin "out" method.

Added:
Just as a bookmark, I found this interesting page: www.mcmanis.com/chuck/robotics/stamp-decode.html (http://www.mcmanis.com/chuck/robotics/stamp-decode.html)
Maybe it will be a good starting point for someone.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Post Edited (jazzed) : 8/5/2009 4:10:11 AM GMT

Dr_Acula
08-05-2009, 12:21 PM
I've been studying some spin and there seem to be lots of 1 to 1 code structures that could translate to and from basic. eg IF and while loops and case. And gosub - could that be equivalent to calling a PRI ?

Ale
08-05-2009, 03:03 PM
I really do not like Basic (I started with it some 24 years ago...) and I passionately dislike the not numbered version http://forums.parallax.com/images/smilies/lol.gif but:

If you are going to make a compiler (Can I ask why ?) please do not make it as dumb as Bascom is.

Error checking is just plain dumb (i.e. not existent):

A = B +C + D

it is illegal syntax but it does "sort" of compiles without giving errors !!!

Where variables are not allowed the compiler does not produce any errors http://forums.parallax.com/images/smilies/eyes.gif

Built-in functions for i2c, adc, lcd usw are nice and super easy to work with but it is just not BASIC anymore. It is a hybrid of m$ basics with some C syntax.

Make it clean, forget about DIM: It should only be used for arrays, for the rest exist the %, !, $ and so on. Make it dynamic as old BASICs where, they did it in 8kbytes why we cannot ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH (http://propeller.wikispaces.com/MATH)
pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL020 (http://propeller.wikispaces.com/pPropQL020)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

he1957
08-05-2009, 07:05 PM
Greetings,

I'd like to know why a BASIC _compiler_ would be a fruitful investment other than "because you can".·

Remember that BASIC == Beginners All-purpose Symbolic Instruction Code; It is very good at this as was intended; Its initial acceptance and subsequent success was based on this foundation.· Examples would be the "Personal Computer" and the "Basic Stamp" albiet their different audiences.· Those choosing or needing to squeeze performance or optimisation always turn to "better" languages/methods for the intended target platform.

One may use BASIC like languages for rapid development and/or code maintainability and the like, but for a microcontroller with optimised code?

Given what I've read in this thread, it seems evident that Parallax needs/wants to expand their Customer base - specifically for Propeller.· This makes good sense.· Until about 2 months ago, I'd never heard of either the Propeller nor Parallax per se; although I have _heard_ of the Basic Stamp.· I've never used one but since my introduction to Propeller about 2 months ago I've been "sold" - Well done Parallax.· My intent of use is Propeller control of custom designed/built machines and the Propeller suits this to a Tee!

I've found from a raw introduction to microcontrollers that the Object Exchange download of the "FemToBasic" (interpretive) code is an extremely elegant introduction to some of Propellers capabilities while also providing the simplicity of what BASIC is and was intended to do.· Not having used a BS but observing there are Obects available that provide the BS2 functions (and names); I'd reckon this project is already available.

This should be advertised because it makes for a perfect match between existing BS users and those that want/need more than what the BS2 has; unless I misunderstand what the mix of the BS2 object with Propeller can do.· I gather SPIN/Assembly can be used in a MAIN routine in SPIN that also uses the BS2 library? -· WOW - now that's _powerful! (unless you can't).

Those needing/wanting· more can just adopt SPIN - a clever mix of different languages and programming styles and constructs.· Need more still: then·GOTO assembly language ;-)

A$0.02



Kind regards,

HarryE.

Dr_Acula
08-05-2009, 08:07 PM
I guess one can neatly sidestep the debate by using Heater/Cluso's zicog. Then you can use C or Fortran or Basic or 8080 assembly or Z80 assembly or Pascal or the list goes on. I've just been using Microsoft's Basic on a Propeller to do some quick testing of input and output ports.

But Harry's comment has me thinking "I gather SPIN/Assembly can be used in a MAIN routine in SPIN that also uses the BS2 library? - WOW - now that's _powerful! (unless you can't)."

Maybe you can? I've been writing some spin code in Notepad and using a little batch file to compile with Homespun or BST. These two programs are amazing pieces of work and there is no reason you could not start adding basic constructs in amongst spin and let the compiler convert to spin on the fly. Many constructs are extremely simple to translate eg:

if variable_1=1 then
variable_2=5
else
variable_3=6
endif

which the compiler translates to

if variable_1 == 1
variable_2 := 5
else
variable_3 := 6

using some rules:
if you find a line with IF at the beginning and then an =, change the = to == and delete the THEN
if you find a line where one variable equals another constant or variable, add a : before the =
if you are on the second line after an IF, add two spaces and correctly indent any ELSE statements until the ENDIF

You could have a list of supported Basic commands and there are ones that are always going to be too hard to add, and there will be ones that actually are easier to use in Spin anyway (eg some of the bit manipulation instructions).

You could even add slabs of code to get beginners coding with the old favourites

PRINT "Hello World"

is compiled to some spin that loads the vga_text object and creates the spin code to send the text "Hello World". So PRINT is converted to something that indeed does print some text on the vga screen. Instant results.

If PRINT is encountered a second time, well the vga_text object already exists so just use it.

A compiler could go directly to bytecode, or it could go via spin. It probably doesn't really matter and you could always produce intermediate .lst files to document the intermediate steps.

I suppose it is a philosophical question as to whether bits of Basic code within Spin is allowed.

Post Edited (Dr_Acula (James Moxham)) : 8/5/2009 1:18:43 PM GMT

jazzed
08-05-2009, 08:44 PM
@Ale, I loathe 20 GOTO 10 BASIC too ... much more than I loathe CPM http://forums.parallax.com/images/smilies/wink.gif

Somehow I gathered that Parallax needed a Basic Stamp PBASIC token interpreter to run on Propeller.
That would of course be much easier to do if they provided a full specification of the tokens (under NDA).
Hacking it might be more fun and less of an IP burden. A compiler and down-loader already exists for PBASIC.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Bean
08-05-2009, 08:51 PM
The "fun" part is compiling commands like SEROUT and SERIN. These commands have a ton of options.

And of course SEROUT (DEBUG) and SERIN (DEBUGIN) are used in alot of BS2 programs.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...




Post Edited (Bean (Hitt Consulting)) : 8/5/2009 4:46:03 PM GMT

JonnyMac
08-05-2009, 10:19 PM
As with SX/B -- a successful product -- I don't think a Propeller BASIC should work too hard to be 100% PBASIC compatible. Heck, none of the BASIC Stamp clones offer that. If Propeller BASIC is close to PBASIC2 with improvements over areas where the Stamp is perceived to be weak (e.g., serial comms) then I think it would be worth doing. It would be interesting to have P/B work like the Javelin with installable objects so that one could, for example, install the FullDuplexSerial object and use it in a BASIC program. It would be a shame to offer a BASIC for the Propeller that didn't buffer serial communications.

he1957
08-06-2009, 07:45 PM
Although many programming languages exist and they each have their pros and cons, I don't know of any that do not use an intermediate process (or multiple passes of similar) to achieve their objective.· Whether their objective is to build object (ie: library related) or machine (direct machine executable) code they all generate some form of translation file to do so, generally as part of their multi-pass process.

Most (if not all) provide (user accessible) flags/switches/directives to allow examination of their transitional files; whether this be for debugging or other purpose.· The point here is that (example) a C pre-processor can show you the #include(ed) files contents/definitions, or, flags can generate assembly listings to see the assembly code generated.· Interestingly enough, the assembly listing can be hand edited for optimisation if one thinks they can do better (or to exploit a specific platform/architecture) if so desired.· All that is then needed is to provide the assembly listing to the next tool chain component to generate the next phase - until the end of the seqeuce is reached (ie: object/machine code).

Propeller is a new approach to micro-controllers.· [I (personally) like the "zero" interrupt capabilities and subsequent omission of the traditional complexities of handlers needed otherwise.]··To exploit this (particular) feature however, requires a different view and approach·for how to implement a Propeller into one's design and deployment.· If replacing an existing "platform" to perform the same tasks then the transition is more trivial.

For a simplistic "replacement" a simple BSx basic language translation would mostly suffice because one is generally replacing one chip for another; functions need only be provided - using (mostly) already developed code.· If this runs 'interpreted' - where is the problem given a single COG runs at some 20MIPS?

Attempting to _compile_ same - while still having to provide functions emulated for a Propellor would surely either run you out of memory or require complex paging mechanisms to allow for the program sizes - surely this loses speed advantages of a 20MIP controller.

In code specifics:

GOTO needs no return address - it will never be needed

GOSUB always needs a return address albiet GOSUB == call == procedure_call (language semantics excluded)

The point here is that GOTO·generates a new PC (ProgramCounter) address and stuffs it into the PC and nothing else matters; procedural calls (or whatever you call them) need a way of coming "home" with restored "state" - try using GOTO [or ld pc, new_add] within subroutines [at any level], lose track of what you've done (or let your code do it for you) and you have a debugging nighmare - mosty evident when stack space is exhausted.

Tokanising (sp?) xyzBASIC into SPIN (using an intermediate file for interpretation) should not be too difficult and would certainly allow easy counting of unbalanced GOSUB/CALL/RETURN pairs; GOTO's only matter when a program(mer) thought it was a good idea to GOTO (PC+some_value) {and do_something} then GOTO (where_they_were) using a conditional to determine they RETURNed.· This type of coding deserves what·it gives·[have I used this? - no comment {kinda like self-modifying code} - err no comet ;-o ] ;-)

I guess my bottom line is that in order to provide transition from·existing·to new platforms is·by using a cushion of familiarity while introducing new/advanced features and benefits.· It's a tough sell!

To re-write X=K's of University/College/Corporate documents or provide a set of directives/flags that do it for you - you choose ;-)

I suppose this could be a multi-part project - first the translation and interpretation, then the assembly and finally the object/machine code!· You could also provide feedback for the user if you figure a "better" way could·be proposed for a "routines" analysis.· ie: code block function rather than in-line translation.· Alas, BASIC probably makes this more difficult unless some initial structure was applied in code design.

BTW: Why do you want a BASIC compiler?· Please don't say because you want to write device drivers ;-)

Kind regards,

HarryE.

he1957
08-06-2009, 09:35 PM
Oops,

Omitted to mention DEBUG is un-required when the code works according to design especially if optimisation is a goal, but, hey;·it's nice·to see progress of·one's work (and proof it's still running) too ;-)· If this be a migration between platforms then DEBUG would generally be an exception and an appropriate flag needs to be available - if required; it would need to invoke a listing file (or program flow/trace) that can be analysed to identify the flaw.

Most code·can (could or does) include a DEBUG(variant|level) flag at the top of the file [easy to edit].·

Appropriate sections then use the variant|level to show what·is expected.· This allows easier section isolation and DEBUG _during development_.· When all works as expected, simply omit all ([disable {all|un-needed}] variants).· If this was compiled, then no DEBUG code need be included in the target object unless a flaw is evident or suspected.

Cheers,

HarryE.

Pepz
11-10-2011, 09:52 AM
I ignored GOTO one time and the program just continued with the next instruction...

Seriously, what's "evil" with telling the IP to point at another adress?
NO program would last more than a few ms without a JMP in the machine code!

Mark my words, I can write you some serious spaghetti-code in SPIN!

I think it's better to kickstart some stuff that works, maybe in a "evil/dirty/ugly" (add bad words here),
than some "flashy/perfect/optimized" (add nice words here), project that never gets built or written.

Conclusion, to get more users (&$$$), of course you should support BASIC and compiled BASIC.
BASIC is still around for a reason, and VB is the most used IDE ever.
Need I say more?

softcon
11-10-2011, 07:06 PM
There's nothing that says the propeller basic has to be identical to the stamp basic. Sure, it's nice to be able to grab your old source, and drop it in to a new compiler, and have it just work, but in reality, this rarely happens, and I suspect most folks will expect this.
What should be done is piggyback on the gcc port to the propeller boards. Gnu already uses gcc for it's backend on nearly all of it's languages, pascal, basic, fortran, and plenty others. After the gcc compiler is working, it's just a matter of adding front-ends for the various languages, and you can even use the gnu ones, since it's all opensource, as long as the source is rereleased back to the community, there's no issue with using it for all the languages available.
That certainly would make many more folks happy.
On the other hand, a quick and dirty translation of existing code to something that will run on the propeller with no changes by the initial developers certainly won't hurt, so it's well worth persuing, but if you can incorporate it with the gcc as a back end mindset somehow, I think you'd have a much more powerful platform when you're done.
Even if that's not your goal, you'd still want to add additional basic commands to allow the stamp basic users take advantage of the new propeller features such as threads.