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...
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.
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
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:
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[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.
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.
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...
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.
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.
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.
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...
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) [noparse]:)[/noparse]
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.
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 [noparse]:)[/noparse].
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.
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.
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.
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:
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 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.
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··that you may have and all of your time finding them
· · · · Sam
Post Edited (sam_sam_sam) : 7/18/2009 8:55:20 PM GMT
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.
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.
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··that you may have and all of your time finding them
· · · · Sam
Post Edited (sam_sam_sam) : 7/18/2009 10:07:17 PM GMT
I vote . 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
@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
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.
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!
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:
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.
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
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...
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 !! 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) .
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!·
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
Comments
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
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
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, 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
A possible solution is in this thread, just add this 2 posts together:
Andy
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...
·
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.
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!
It would also be a good alternative to C and SPIN.
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) [noparse]:)[/noparse]
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!
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://forums.parallax.com/showthread.php?p=788230
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.
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.
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, 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
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
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.
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·
·
·
·
·
Sam
Post Edited (sam_sam_sam) : 7/18/2009 8:55:20 PM GMT
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.
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·
·
·
·
·
Sam
Post Edited (sam_sam_sam) : 7/18/2009 10:07:17 PM GMT
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=outstringI'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
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax posesses power beyond belief.
Believe in it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
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
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...
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
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
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!·
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