Propeller BASIC compiler ideas...
Bean
Posts: 8,129
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
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...
·
A) BASIC to Propeller Assembly
······ Could use to make video/hardware drivers
······ Limited to 497 assembly instructions
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...
·
Comments
A) is limited by code size but would go like a bat out of hell.
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 [noparse];)[/noparse]
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!
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 ...
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!
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Adding the special Stamp basic commands would help bring a lot of Stamp users over...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Morpheus & Mem+ 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
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: [noparse][[/noparse]url]http://forums.parallax.com/forums/default.aspx?f=25&m=349616&p=2[noparse][[/noparse]/url].
Post Edited (Mike Green) : 7/16/2009 4:21:12 PM GMT
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
It would allow for fewer limits in regard to code.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
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...
·
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.
I add my vote for structured (not line numbered) BASIC to bytecode; with appropriate Spin functions added to the BASIC language.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andrew Williams
WBA Consulting
IT / Web / PCB / Audio
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.
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!
The best reference is the interpreter source.
If you want a hacky way of testing stuff, bst[noparse][[/noparse]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!
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.'
·
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!!··
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.
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.
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, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm