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.
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.
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+ Advanced dual Propeller SBC with XMM and 256 Color VGA - PCB, kit, A&T available NOW! 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
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.
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+ Advanced dual Propeller SBC with XMM and 256 Color VGA - PCB, kit, A&T available NOW! 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
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
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
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 [noparse]:)[/noparse]
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.
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 ?
I really do not like Basic (I started with it some 24 years ago...) and I passionately dislike the not numbered version 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
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 ?
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 ;-)
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
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
@Ale, I loathe 20 GOTO 10 BASIC too ... much more than I loathe CPM
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.
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.
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.· [noparse][[/noparse]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
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 [noparse][[/noparse]or ld pc, new_add] within subroutines [noparse][[/noparse]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·[noparse][[/noparse]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 ;-)
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 [noparse][[/noparse]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 ([noparse][[/noparse]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.
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?
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.
Comments
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...
is exactly the same as:
pub main do ' something loopGOTO (which assembles to jmp) is cleaner to use when the "something" section is substantial.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+ Advanced dual Propeller SBC with XMM and 256 Color VGA - PCB, kit, A&T available NOW!
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
My bad, for some reason I thought Bean was taking about PBASIC. I should have read higher in the thread!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+ Advanced dual Propeller SBC with XMM and 256 Color VGA - PCB, kit, A&T available NOW!
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
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
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
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 [noparse]:)[/noparse]
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
Maybe it will be a good starting point for someone.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 8/5/2009 4:10:11 AM GMT
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
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
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
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.
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
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://forums.parallax.com/showthread.php?p=788230
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
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.· [noparse][[/noparse]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 [noparse][[/noparse]or ld pc, new_add] within subroutines [noparse][[/noparse]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·[noparse][[/noparse]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.
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 [noparse][[/noparse]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 ([noparse][[/noparse]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.
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?
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.