Image showing dockable code editor windows and auto complete for DO...LOOP template.
New additions:
1. Auto complete for DO..LOOP, IF..THEN, FOR..NEXT (all variations), SUB..ENDSUB, FUNC..ENDFUNC, TASK..ENDTASK templates as well as Key Words etc.
2. Auto indentation
3. DO..LOOP and FOR.. NEXT outline code folding.
4. Terminal Window can be docked above/below or on the sides of a code window.
1. To PDF File (Always useful)
2. To HTML File (Useful if you want to put syntax highlighted code in a web page)
3. To Rich Text File (Useful if want to add syntax highlighted code to a word document)
1. To PDF File (Always useful)
2. To HTML File (Useful if you want to put syntax highlighted code in a web page)
3. To Rich Text File (Useful if want to add syntax highlighted code to a word document)
Cheers.
This is very promising. Thanks to both Batang and Bean.!
1. To PDF File (Always useful)
2. To HTML File (Useful if you want to put syntax highlighted code in a web page)
3. To Rich Text File (Useful if want to add syntax highlighted code to a word document)
I just wanted to let everyone know that Batang and I have been working on the IDE and quite a few changes to PropBasic.
It seems to be going pretty well so far. The relationship seem good.
The version of PropBasic released with PropBasic Studio will be version 2 (PropBasic2).
Then there will be another release of PropBasic (PropBasic3) that will be a total re-write. More like a traditional BASIC language.
Full expression evaluation for all parameters.
Local variables for subroutines/function.
Common commands will be subroutines instead of generated in-line.
All code will be LMM. (TASKs can be PASM for video drivers etc.)
All variables will be stored in HUB ram.
Integrated Debugger.
Will support the Propeller2 (maybe not the initial release).
PropBasic3 is probably a year away, but I thought I would let everyone know my plans.
I just wanted to let everyone know that Batang and I have been working on the IDE and quite a few changes to PropBasic.
It seems to be going pretty well so far. The relationship seem good.
The version of PropBasic released with PropBasic Studio will be version 2 (PropBasic2).
Then there will be another release of PropBasic (PropBasic3) that will be a total re-write. More like a traditional BASIC language.
Full expression evaluation for all parameters.
Local variables for subroutines/function.
Common commands will be subroutines instead of generated in-line.
All code will be LMM. (TASKs can be PASM for video drivers etc.)
All variables will be stored in HUB ram.
Integrated Debugger.
Will support the Propeller2 (maybe not the initial release).
PropBasic3 is probably a year away, but I thought I would let everyone know my plans.
Bean
Truly fantastic news!
You and Batang need one of those PayPal Donate button thingies
Hi,
writing as an old fan and user of PropBasic:
1. These activities are great!
2. perhaps you might include the existing debugging feature into the ide. I found it helpful.
3. Bean, the possibility to compile to cog code for fast basic instead of pasm drivers is THE key advantage over spin. Perhaps you want to leave a path open for such a feature for later releases? (Why did a simple guy like me use PropBasic? Because he wants to have speed and did not feel firm to write pasm. And because this language has not much overhead and the docu was good enough and reliable.)
Just my thoughts... Thanks Christof
I just wanted to let everyone know that Batang and I have been working on the IDE and quite a few changes to PropBasic.
It seems to be going pretty well so far. The relationship seem good.
The version of PropBasic released with PropBasic Studio will be version 2 (PropBasic2).
Sounds good.
I grabbed the example in this thread & fed into FreeBASIC. to use as a functional simulator & structural debug.
Where a function did not exist, I created a dummy wrapper
It does look quite close, with some simple alias good to solve a couple of issues
* Allow CONST as alternative to CONSTANT
* Allow RANDOMn as alternative to RANDOM (RANDOM is a file keyword in FreeBASIC)
or add alternate format as y = Rnd( seed )
* Allow Function calls syntax to be open list or (param list) - ie tolerate ()
fbc requires () on function calls, & can either use () or not on Sub calls
Personally, I prefer to use () on all calls, for consistency and common with other languages.
* Tolerate keyword after EXIT (fbc needs EXIT DO, for example )
and allow #IFDEF flow alias for preprocessor, for the cases needing any fixups..
A good quick summary of FreeBASIC keywords is here :
' ------------------------------------------------------------------------
' This demo program moves 1000 dots around on a NTSC screen.
' ------------------------------------------------------------------------
' Edited to compile in FreeBasic - Param details not checked.
'
' Define CONs
CONST NumDots = 1000 ' CONSTANT NumDots = 1000
CONST MaxDots = 999 ' CONSTANT MaxDots = 999
' Define HUB variables
DIM dots(NumDots) AS LONG ' x, y, xdir, ydir ~HUB
'DIM dots AS HUB LONG(NumDots) ' x, y, xdir, ydir ~HUB
' Define variables (LONGs only)
DIM curDot AS LONG
DIM dotsAddr AS LONG
DIM X AS LONG
DIM Y AS LONG
DIM dirX AS LONG
DIM dirY AS LONG
DIM seed AS LONG
DIM temp AS LONG
#IFDEF __FB_WIN32__ 'Defined in Windows FreeBasic
SUB PAUSE ( byval amount as integer )
Sleep amount
END SUB
' fbc prefers specific type per parameter
SUB RDBYTE (dotsAddr as integer, x as integer, y as integer, dirX as integer, dirY as integer)
END SUB
' fbc allows line-continue _
SUB WRBYTE (dotsAddr as integer,_
x as integer,_
y as integer,_
dirX as integer,_
dirY as integer)
END SUB
SUB TV_XPlot (x as integer, y as integer)
END SUB
function GETADDR ( va as LONG) as LONG
GETADDR = va
end function
SUB RANDOMn ( seed as LONG, y as LONG ) ' RANDOM is a reserved word
y = Rnd( seed )
END SUB
#ELSE 'For targets other than Windows (eg PropBASIC), add custom stuff here
#ENDIF
' Start of main code
' ~SUB MAIN
dotsAddr = GETADDR(dots(0)) 'fbc requires () ~ dotsAddr = GETADDR dots
FOR curDot = 0 TO MaxDots
RANDOMn (seed, x) 'RANDOM seed, x fbc allows () or no ()
x = x AND 255
DO
RANDOMn seed, y 'RANDOM seed, y
y = y AND 255
LOOP UNTIL y < 192
DO
RANDOMn seed, dirX ' RANDOM seed, dirX
dirX = dirX AND 255
dirX = dirX / 52
RANDOMn seed, dirY ' RANDOM seed, dirY
dirY = dirY AND 255
dirY = dirY / 52
IF dirX <> 2 OR dirY <> 2 THEN EXIT DO 'THEN EXIT
LOOP
WRBYTE dotsAddr, x, y, dirX, dirY
TV_XPlot x, y
dotsAddr = dotsAddr + 4
NEXT
DO
dotsAddr = GETADDR(dots(0)) ' dotsAddr = GETADDR dots
FOR curDot = 0 TO MaxDots
RDBYTE dotsAddr, x, y, dirX, dirY
TV_XPlot x, y
x =x + dirX
x = x - 2
IF x > 255 OR x < 0 THEN
dirX = 4 - dirX
x = x + dirX
x = x - 2
ENDIF
y = y + dirY
y = y - 2
IF y > 191 OR y < 0 THEN
dirY = 4 - dirY
y = y + dirY
y = y - 2
ENDIF
TV_XPlot x, y
WRBYTE dotsAddr, x, y, dirX, dirY
dotsAddr = dotsAddr + 4
NEXT
PAUSE 10
LOOP
END
' ENDSUB
The version of PropBasic released with PropBasic Studio will be version 2 (PropBasic2).
Then there will be another release of PropBasic (PropBasic3) that will be a total re-write. More like a traditional BASIC language.
...
All code will be LMM. (TASKs can be PASM for video drivers etc.)
...
Bean
Long live PropBasic2!
Any chance that PB2 might be used to pre-compile tasks as native cog code to be loaded by PB3? Since as you pointed out in another thread, main programs are often LMM, there wouldn't be a speed penalty to have the benefits of your planned changes for PB3. For cog code, PB2 is still a significant step in abstraction and convenience above assembler.
Either way, thanks for your hard work, Bean. From what I've seen so far, I'll still be pretty happy just with PB2 and PB Studio.
Jones,
The code from PropBasic2 will most likely not work in PropBasic3 because ALL variables will be in HUB ram instead of COG ram.
Usually if you need really fast speed (video drivers, etc) you are going to want to use PASM anyway.
Yes, I have written a couple video drivers in PropBasic, but you need to really "know" the compiler to do that. And that code still will not be as fast as PASM code.
It's just not worth the effort to make basically two compilers (one for native code and one for LMM).
My experience tell me that if you need the speed of native code, there are very few situations where compiled PropBasic code is going to work well.
Usually if you need really fast speed (video drivers, etc) you are going to want to use PASM anyway.
Yes, I have written a couple video drivers in PropBasic, but you need to really "know" the compiler to do that. And that code still will not be as fast as PASM code.
but it is much faster than Spin, right ? - and users can in-line as much PASM as they want to ?
It's just not worth the effort to make basically two compilers (one for native code and one for LMM).
My experience tell me that if you need the speed of native code, there are very few situations where compiled PropBasic code is going to work well.
Even if it is not quite as fast as Pure-PASM (no compiler will be) I see a strong place for a 'High level Assembler' - ie a simple language that can create COG-resident code, as that lets users 'get at' the silicon power better.
Well commented PASM output, (perhaps even with delay estimates), will also help teach users PASM itself.
Taking an example from another thread, a user wants to wait on a Pin, and also an Exit flag.
Seems a fairly common usage.
We have this code and comment : ["repeat until ina[tstop] == 0 or BYTE[stopadr] == 1
takes more than 1 us (more like 10us), so you will not get a resolution of 1 us with that code."]
What is the equivalent code in PropBASIC, and what PASM would it create ?
Even if it is not quite as fast as Pure-PASM (no compiler will be) I see a strong place for a 'High level Assembler' - ie a simple language that can create COG-resident code, as that lets users 'get at' the silicon power better.
I'm not sure if you consider it a "simple language" but Propeller C can generate COG-resident code. C has been called a "universal assembler" by some.
I'm not sure if you consider it a "simple language" but Propeller C can generate COG-resident code. C has been called a "universal assembler" by some.
Yes, that detail of PropC has real appeal.
Perhaps you could do the classic waiting code-line above, in Prop C and we can compare Generated PASM with PropBASIC (when posted), and a variant using in-line PASM, if that offers any further improvement.
And here I thought I was the only one waiting for this. You guys ROCK. I can't wait to see the full blown program running on my systems. And as @Mickster said, you guys need a PayPal Donation account. Having written a lot of code in the past I know that it is a time consuming and grueling process to get everything to work the way you want and the way others expect!!!!
Comments
I look forward to testing this when it is ready.
Jim
Dave
Image showing dockable code editor windows and auto complete for DO...LOOP template.
New additions:
1. Auto complete for DO..LOOP, IF..THEN, FOR..NEXT (all variations), SUB..ENDSUB, FUNC..ENDFUNC, TASK..ENDTASK templates as well as Key Words etc.
2. Auto indentation
3. DO..LOOP and FOR.. NEXT outline code folding.
4. Terminal Window can be docked above/below or on the sides of a code window.
Cheers.
http://prx.sytes.net/PropBasicStudio_Update.png
Keep up the good work-
Looking forward to trying it out
Dave
1. To PDF File (Always useful)
2. To HTML File (Useful if you want to put syntax highlighted code in a web page)
3. To Rich Text File (Useful if want to add syntax highlighted code to a word document)
Cheers.
This is very promising. Thanks to both Batang and Bean.!
Thanks,
Massimo
Nice.
I would suggest
a) including the compiler(s) as then users know they have correct 'as tested' version matches.
b) check the FreeBasic compiler command line, and include an option for fbc compile for PC-hosted testing. (and some debug, via )
Also, for Bean, I see FreeBasic supports this common pre-processor syntax
#DEFINE YellowOnGreen
#IFDEF YellowOnGreen
so if PropBASIC expanded its IFDEF to include this, users can mix PC/Prop test codes.
It seems to be going pretty well so far. The relationship seem good.
The version of PropBasic released with PropBasic Studio will be version 2 (PropBasic2).
Then there will be another release of PropBasic (PropBasic3) that will be a total re-write. More like a traditional BASIC language.
Full expression evaluation for all parameters.
Local variables for subroutines/function.
Common commands will be subroutines instead of generated in-line.
All code will be LMM. (TASKs can be PASM for video drivers etc.)
All variables will be stored in HUB ram.
Integrated Debugger.
Will support the Propeller2 (maybe not the initial release).
PropBasic3 is probably a year away, but I thought I would let everyone know my plans.
Bean
Jeff
Truly fantastic news!
You and Batang need one of those PayPal Donate button thingies
Regards,
Mickster
-Mike
Included here is a PDF giving an example of the new ProBasic syntax as well the IDE highlighting and so on.
Although the language may be "Basic" you can rapidly write code and as PropBasic compiles to assembly get high speed performance.
PropBasicSample.pdf
writing as an old fan and user of PropBasic:
1. These activities are great!
2. perhaps you might include the existing debugging feature into the ide. I found it helpful.
3. Bean, the possibility to compile to cog code for fast basic instead of pasm drivers is THE key advantage over spin. Perhaps you want to leave a path open for such a feature for later releases? (Why did a simple guy like me use PropBasic? Because he wants to have speed and did not feel firm to write pasm. And because this language has not much overhead and the docu was good enough and reliable.)
Just my thoughts... Thanks Christof
Sounds good.
I grabbed the example in this thread & fed into FreeBASIC. to use as a functional simulator & structural debug.
Where a function did not exist, I created a dummy wrapper
It does look quite close, with some simple alias good to solve a couple of issues
* Allow CONST as alternative to CONSTANT
* Allow RANDOMn as alternative to RANDOM (RANDOM is a file keyword in FreeBASIC)
or add alternate format as y = Rnd( seed )
* Allow Function calls syntax to be open list or (param list) - ie tolerate ()
fbc requires () on function calls, & can either use () or not on Sub calls
Personally, I prefer to use () on all calls, for consistency and common with other languages.
* Tolerate keyword after EXIT (fbc needs EXIT DO, for example )
and allow #IFDEF flow alias for preprocessor, for the cases needing any fixups..
A good quick summary of FreeBASIC keywords is here :
http://www.freebasic.net/wiki/wikka.php?wakka=CatPgFullIndex
' ------------------------------------------------------------------------ ' This demo program moves 1000 dots around on a NTSC screen. ' ------------------------------------------------------------------------ ' Edited to compile in FreeBasic - Param details not checked. ' ' Define CONs CONST NumDots = 1000 ' CONSTANT NumDots = 1000 CONST MaxDots = 999 ' CONSTANT MaxDots = 999 ' Define HUB variables DIM dots(NumDots) AS LONG ' x, y, xdir, ydir ~HUB 'DIM dots AS HUB LONG(NumDots) ' x, y, xdir, ydir ~HUB ' Define variables (LONGs only) DIM curDot AS LONG DIM dotsAddr AS LONG DIM X AS LONG DIM Y AS LONG DIM dirX AS LONG DIM dirY AS LONG DIM seed AS LONG DIM temp AS LONG #IFDEF __FB_WIN32__ 'Defined in Windows FreeBasic SUB PAUSE ( byval amount as integer ) Sleep amount END SUB ' fbc prefers specific type per parameter SUB RDBYTE (dotsAddr as integer, x as integer, y as integer, dirX as integer, dirY as integer) END SUB ' fbc allows line-continue _ SUB WRBYTE (dotsAddr as integer,_ x as integer,_ y as integer,_ dirX as integer,_ dirY as integer) END SUB SUB TV_XPlot (x as integer, y as integer) END SUB function GETADDR ( va as LONG) as LONG GETADDR = va end function SUB RANDOMn ( seed as LONG, y as LONG ) ' RANDOM is a reserved word y = Rnd( seed ) END SUB #ELSE 'For targets other than Windows (eg PropBASIC), add custom stuff here #ENDIF ' Start of main code ' ~SUB MAIN dotsAddr = GETADDR(dots(0)) 'fbc requires () ~ dotsAddr = GETADDR dots FOR curDot = 0 TO MaxDots RANDOMn (seed, x) 'RANDOM seed, x fbc allows () or no () x = x AND 255 DO RANDOMn seed, y 'RANDOM seed, y y = y AND 255 LOOP UNTIL y < 192 DO RANDOMn seed, dirX ' RANDOM seed, dirX dirX = dirX AND 255 dirX = dirX / 52 RANDOMn seed, dirY ' RANDOM seed, dirY dirY = dirY AND 255 dirY = dirY / 52 IF dirX <> 2 OR dirY <> 2 THEN EXIT DO 'THEN EXIT LOOP WRBYTE dotsAddr, x, y, dirX, dirY TV_XPlot x, y dotsAddr = dotsAddr + 4 NEXT DO dotsAddr = GETADDR(dots(0)) ' dotsAddr = GETADDR dots FOR curDot = 0 TO MaxDots RDBYTE dotsAddr, x, y, dirX, dirY TV_XPlot x, y x =x + dirX x = x - 2 IF x > 255 OR x < 0 THEN dirX = 4 - dirX x = x + dirX x = x - 2 ENDIF y = y + dirY y = y - 2 IF y > 191 OR y < 0 THEN dirY = 4 - dirY y = y + dirY y = y - 2 ENDIF TV_XPlot x, y WRBYTE dotsAddr, x, y, dirX, dirY dotsAddr = dotsAddr + 4 NEXT PAUSE 10 LOOP END ' ENDSUB1. A complete list of SPIN keywords in text file format.
2. A complete list of PASM mnemonics in text file format.
Thanks in advance.
BASIC is an acronym for "Beginner's All-purpose Symbolic Instruction Code" so should be spelled in UPPERCASE, right? So is it PropBasic? or PropBASIC?
Just some food for thought.
Having said that, nice effort, guys! I especially like the formatting example, makes even BASIC readable, to me :-)
dgately
PropBasic is a version of BASIC
Bean
Long live PropBasic2!
Any chance that PB2 might be used to pre-compile tasks as native cog code to be loaded by PB3? Since as you pointed out in another thread, main programs are often LMM, there wouldn't be a speed penalty to have the benefits of your planned changes for PB3. For cog code, PB2 is still a significant step in abstraction and convenience above assembler.
Either way, thanks for your hard work, Bean. From what I've seen so far, I'll still be pretty happy just with PB2 and PB Studio.
The code from PropBasic2 will most likely not work in PropBasic3 because ALL variables will be in HUB ram instead of COG ram.
Usually if you need really fast speed (video drivers, etc) you are going to want to use PASM anyway.
Yes, I have written a couple video drivers in PropBasic, but you need to really "know" the compiler to do that. And that code still will not be as fast as PASM code.
It's just not worth the effort to make basically two compilers (one for native code and one for LMM).
My experience tell me that if you need the speed of native code, there are very few situations where compiled PropBasic code is going to work well.
Bean
but it is much faster than Spin, right ? - and users can in-line as much PASM as they want to ?
Even if it is not quite as fast as Pure-PASM (no compiler will be) I see a strong place for a 'High level Assembler' - ie a simple language that can create COG-resident code, as that lets users 'get at' the silicon power better.
Well commented PASM output, (perhaps even with delay estimates), will also help teach users PASM itself.
Taking an example from another thread, a user wants to wait on a Pin, and also an Exit flag.
Seems a fairly common usage.
We have this code and comment :
["repeat until ina[tstop] == 0 or BYTE[stopadr] == 1
takes more than 1 us (more like 10us), so you will not get a resolution of 1 us with that code."]
What is the equivalent code in PropBASIC, and what PASM would it create ?
Yes, that detail of PropC has real appeal.
Perhaps you could do the classic waiting code-line above, in Prop C and we can compare Generated PASM with PropBASIC (when posted), and a variant using in-line PASM, if that offers any further improvement.
Thanks!
Jeff
Maybe a "paying gig" got priority ???
Bean
this http://forums.parallax.com/showthread.php/148487-Drops-Rain-and-Sleep-...-and-the-Prop-using-PropBasic
was possible only because of the outstanding feature of PropBasic to generate very fast Cog- Code.
Thanks a lot!!!
Christof
Hi Guys,
Bean nailed it with the above quote, I have been up to eyeballs with work these last few weeks and will have it cleared over this coming weekend.
Then it will be about 2 weeks until a beta release.
Cheers.