The source code to MMBasic is Copyright 2011 - 2018 Geoff Graham and may be used for an individual's personal use under the following terms:
The files may not be distributed or made available to others without specific written permission.
Object files (ie, .o, .exe, .hex files) generated using one or more of the source files (modified or not) are for personal use only and may not be distributed without written permission.
The files are provided without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose.
The source is not open and (probably) MMBASIC is a one man show. Does that remind someone of BST?
Geoff Graham (OZ) and Pete Matherp (UK) are now the developers....and Pete, especially, seems to have a new development every day.
I really have no interest in open source...it works or it doesn't. I care about shipping a product that works and rapid development is what I need.
The guy who developed Bypic (Micromite on steroids) just retired but I have the hex file and a PICkit3....it works.
Not a fan of Windows but it helps me get the job done and I get paid....can't make Linux work for me....which one is open source?
I am astounded at the faith that my clients have in myself. I am now a one-man-band with a proprietary product. In many cases, if my product dies, there's a whole bunch of people stood on a factory floor with nothing to do.
In my previous life I shipped enough product in to Big 3 auto that would shut down an entire car production line... We only ever negotiated price, never source code.
In its minimal version MMBasic typically compiles to about 94K of flash and requires just over 5K of RAM plus a minimum of 4K for the stack (9K total).
More memory is required to store programs, variables, etc so the interpreter will require at least 16K of RAM to run a small BASIC program.
Generally 32K RAM or more is preferred as that will allow for larger programs and arrays.
Keep in mind that adding extra functionality (SD card support, file I/O, etc) will add to these requirements.
Customisation
The language itself is hardware independent. Supporting the language are two main files that will need customisation to suit a particular platform:
Main.c - This is the main entry point and is responsible for configuring the chip, basic character I/O and the main loop which inputs a line and dispatches it to the interpreter.
Memory.c - This allocates RAM for the interpreter's use (program memory, variable memory and the heap).
The configuration of this has been kept flexible so that the language can run on devices with unusual memory mapping.
MMBasic has its own dynamic heap system which is also implemented in this file."
Which all looks pretty nifty, and could even give a path for Parallax to offer module versions, once ported, so that could actually be a nice "Bridge Product"
It's meaty, so be very interesting to see how that .c compiles into P2.
If nothing else, it's a great test pattern for any P2 C Compilers !!!
Back to the main topic, this was offered as another alternative, in that question equivalent to : AVR C projects needs small interpreter for customer sand box use
Requires roughly 55 KB program memory
Initializes in 4KB RAM; print "hello world" needs 5KB; 8KB is the minimum recommended RAM.
Supports integers, floats, tuples, lists, dicts, functions, modules, classes, generators, decorators and closures
Supports 25 of 29 keywords and 89 of 112 bytecodes from Python 2.6
Can run multiple stackless green threads (round-robin)
Has a mark-sweep garbage collector
Has a hosted interactive prompt for live coding
Licensed under the GNU GPL ver. 2
The PyMite VM DOES NOT HAVE:
A built-in compiler
Any of Python's libraries (no batteries included)
A ready-to-go solution for the beginner (you need to know C and how to work with microcontrollers)
FAQ:
'How much RAM is necessary? A: At least 5 KB to initalize, 8 KB to do something small and more KB if your goals are lofty.
I just built the latest release, why does it fail? A: Please use the latest code from the repository rather than the releases. The release is showing its age and many bugs have been fixed in the repository.
Why does this simple for-loop fail ? for i in range(1, 10000): print i
A: The range() function creates a List with the given number of integers inside it. That list and its contents are consuming all the available RAM. Use xrange() or while() with a counter instead.
Another great C test pattern
Whilst the MMBasic above is looking 'meaty' at ~94kF 5k+4k RAM, for a Basic, it's a natural growth point in MCU space
The PyMite VM at 55kF,4kR starting, looks a nifty parsimonious Python Byte code starting point.
line up nicely here, and that 96kRAM in the LPC51U68, looks good for this type of interpreter payload.
One can look at those numbers, and then look at Chips' highly optimized ByteCode PASM backend in Spin2, a blender, and start to imagine a P2 C/PASM project, that could spit out
a P2 image of a Python Interpreter....
(c) guppy: short for "Grand Unified Propeller Programming sYstem". The dialects would be "Guppy BASIC", "Guppy Spin", etc. Seems a bit friendlier than "multiprop", but not as professional.
I think that this name would be appropriate: guppy - BASIC like compiler. How professional sounding is Python or Perl, or...
This is your creation, so the name is your creation, go for it.
Any gluttons for punishment who want to try out the (unfinished, undocumented, unsupported) BASIC support in fastspin can grab the latest binary release from https://github.com/totalspectrum/spin2cpp/releases. Simple integer programs are working, and serial I/O to the default port works. Instead of floating point the "single" type is 16.16 fixed point (eventually this will be replaced by real IEEE float).
Did you port Bean's Frequency Counters ok ? ( Simple & Reciprocal versions published - reciprocal gives 0.5Hz ~ 40MHz, at close to 8 digits/s precision )
I'm porting your example from the other thread, to the FreeBASIC/PC
FB gives this
P2_Basic_Fibo_Test.bas(26) error 146: Default types or suffixes are only valid in -lang deprecated or fblite or qb, found ')' in ' function fibo(n)'
P2_Basic_Fibo_Test.bas(27) error 31: Expected 'THEN', found 'return' in 'if (n < 2) return n'
P2_Basic_Fibo_Test.bas(36) error 145: Only valid in -lang deprecated or fblite or qb, found 'let' in 'let start = getcnt()'
P2_Basic_Fibo_Test.bas(38) error 41: Variable not declared, i in 'for i = 1 to 10'
P2_Basic_Fibo_Test.bas(38) error 3: Expected End-of-Line, found ' i' in 'for i = 1 to 10'
P2_Basic_Fibo_Test.bas(40) error 145: Only valid in -lang deprecated or fblite or qb, found 'let' in 'let x = fibo(i)'
P2_Basic_Fibo_Test.bas(42) error 3: Expected End-of-Line, found ' i' in 'print "fibo "; i; " = "; x,'
P2_Basic_Fibo_Test.bas(44) error 14: Expected identifier, found ' i' in 'next i'
but no brickwalls, I'll post the PC results shortly...
Here is the PC port from your P2 code.... - went quite smoothly, and hopefully, this code (with emulation bits trimmed) can eventually compile in your compiler fine ?
' P2_Basic_Fibo_Test.bas
' FreeBasic PC Port of code posted http://forums.parallax.com/discussion/comment/1445698/#Comment_1445698
' Original Code posted : before porting snapshot
' function fibo(n)
' if (n < 2) return n
' return fibo(n-1) + fibo(n-2)
' end function
'
' dim as uinteger cycles
'
' waitcnt(getcnt() + 80_000_000)
' print "BASIC fibo demo"
'
' let start = getcnt()
'
' for i = 1 to 10
' cycles = getcnt()
' let x = fibo(i)
' cycles = getcnt() - cycles
' print "fibo "; i; " = "; x,
' print "took "; cycles, "cycles ("; cycles / 80.0; " us)"
' next i
'
' ~~~~~~~~~~~~~~~~~~~~~~~~~~ Emulation Lib ~~~~~~~~~~~~~~~~~~~~~~~~~
Declare Function getcnt() As uinteger '+ Drop in my P1 Emulate routines
Declare Sub WAITCNT (WaitForwardValue As uinteger) '+
' ~~~~~~~~~~~~~~~~ Code, as from WEB, # tags changes needed to FB compile ~~~~~~~~~~~~~~~~
function fibo(n As uinteger) As uinteger '# fixed from function fibo(n)
if (n < 2) then return n '# if (n < 2) return n - original missed 'then'
return fibo(n-1) + fibo(n-2)
end function
dim as uinteger cycles, i '# needed to add i in FB
waitcnt(getcnt() + 80000000) '# No 80_000_000 yet in FB
print "BASIC fibo demo FreeBasic on PC Version" 'E print "BASIC fibo demo"
Var start = getcnt() '# let start = getcnt()
for i = 1 to 25
cycles = getcnt()
Var x = fibo(i) '# let x = fibo(i)
cycles = getcnt() - cycles
print "fibo "; i; " = "; x,
print "took "; cycles, "cycles ("; cycles / 80.0; " us)"
next i
Sleep '+ FB on PC waits for key here
' ~~~~~~~~~~~~~~~~~~~ Libray PC emulates Prop Timers ~~~~~~~~~~~~~~~~~~~~~~~~~
' FB Docs : If the processor has a precision timer (as the Performance Counter Pentium processors from Intel have) and the OS uses it,
' the precision is linked to the processor clock and microseconds can be expected.
' First we define some Prop SysCLK times
Const As Double tP1_CLK = 1/80.0e6 ' Period of PropSysCLK
Const As Uinteger t1ms = CUint(.001/(1/80.0e6)) ' Sysclks in 1ms
Dim Shared As Double StartD,EndD ' Debug capture the fractional polling dT
Dim Shared as uinteger PollCheck ' Debug var
Const As Uinteger FREQ = 80000000
Const As Uinteger ONESEC = FREQ + 4 ' Common Prop defines
Function getcnt() As uinteger
return CUint(Timer/tP1_CLK)
end function
Sub WAITCNT (WaitForwardValue As uinteger)
' Coded to do MOST of delay in sleep(), but that is coarse, and has poor jitter, so the final timeout uses a fast-poll of PCs
VAR SleepRounded = ((WaitForwardValue-getcnt())/t1ms)-21 ' 20ms OK, Experimental trim-down, need finite loops 16,18ms fail 19ms is marginal, choose 21ms - test on other PC's ?
if SleepRounded >= 0 then
Sleep(SleepRounded) 'round down, so most of time is Sleep,
end if
Var AbsDiff = ABS(WaitForwardValue-getcnt() ) ' 99% of time this is small, but in rare cases, getcnt will be MAX, and WaitForwardValue will have wrapped
PollCheck = 0
StartD = Timer()
While AbsDiff >= ABS(WaitForwardValue-getcnt() ) ' look for reversal of setpoint diff, diff decreases until it hits match, then starts to increase.
AbsDiff = ABS(WaitForwardValue-getcnt() )
PollCheck = PollCheck + 1
wend
EndD = Timer()
end Sub
'~~~~~~~~~~~~~~~~~~~~~~~~~ Original P2 reports ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
' Which produced this output:
' $ ./loadp2 fibo.binary -t
' [ Entering terminal mode. Press ESC to exit. ]
' BASIC fibo demo
' fibo 1 = 1 took 147 cycles (1.8359 us)
' fibo 2 = 1 took 380 cycles (4.7500 us)
' fibo 3 = 2 took 600 cycles (7.5000 us)
' fibo 4 = 3 took 1048 cycles (13.0937 us)
' fibo 5 = 5 took 1732 cycles (21.6250 us)
' fibo 6 = 8 took 2876 cycles (35.9375 us)
' fibo 7 = 13 took 4708 cycles (58.7500 us)
' fibo 8 = 21 took 7656 cycles (95.6250 us)
' fibo 9 = 34 took 12380 cycles (154.7500 us)
' fibo 10 = 55 took 20060 cycles (250.5000 us)
' ~~~~~~~~~~~~~~~~~~~~~ PC reports ~~~~~~~~~~~~~~~~~~~~~~
' BASIC fibo demo FreeBasic on PC Version
' fibo 1 = 1 took 26 cycles ( 0.325 us)
' fibo 2 = 1 took 25 cycles ( 0.3125 us)
' fibo 3 = 2 took 26 cycles ( 0.325 us)
' fibo 4 = 3 took 26 cycles ( 0.325 us)
' fibo 5 = 5 took 51 cycles ( 0.6375 us)
' fibo 6 = 8 took 51 cycles ( 0.6375 us)
' fibo 7 = 13 took 77 cycles ( 0.9625 us)
' fibo 8 = 21 took 52 cycles ( 0.65 us)
' fibo 9 = 34 took 102 cycles ( 1.275 us)
' fibo 10 = 55 took 77 cycles ( 0.9625 us)
'
' larger run
' BASIC fibo demo FreeBasic on PC Version
' fibo 1 = 1 took 0 cycles ( 0 us)
' fibo 2 = 1 took 26 cycles ( 0.325 us)
' fibo 3 = 2 took 26 cycles ( 0.325 us)
' fibo 4 = 3 took 26 cycles ( 0.325 us)
' fibo 5 = 5 took 51 cycles ( 0.6375 us)
' fibo 6 = 8 took 51 cycles ( 0.6375 us)
' fibo 7 = 13 took 51 cycles ( 0.6375 us)
' fibo 8 = 21 took 77 cycles ( 0.9625 us)
' fibo 9 = 34 took 103 cycles ( 1.2875 us)
' fibo 10 = 55 took 153 cycles ( 1.9125 us)
' fibo 11 = 89 took 179 cycles ( 2.2375 us)
' fibo 12 = 144 took 256 cycles ( 3.2 us)
' fibo 13 = 233 took 410 cycles ( 5.125 us)
' fibo 14 = 377 took 770 cycles ( 9.625 us)
' fibo 15 = 610 took 1104 cycles ( 13.8 us)
' fibo 16 = 987 took 1719 cycles ( 21.4875 us)
' fibo 17 = 1597 took 2771 cycles ( 34.6375 us)
' fibo 18 = 2584 took 4413 cycles ( 55.1625 us)
' fibo 19 = 4181 took 7210 cycles ( 90.125 us)
' fibo 20 = 6765 took 7697 cycles ( 96.21250000000001 us)
' fibo 21 = 10946 took 12496 cycles ( 156.2 us)
' fibo 22 = 17711 took 20142 cycles ( 251.775 us)
' fibo 23 = 28657 took 32560 cycles ( 407 us)
' fibo 24 = 46368 took 53471 cycles ( 668.3875000000001 us)
' fibo 25 = 75025 took 85314 cycles ( 1066.425 us)
Did you port Bean's Frequency Counters ok ? ( Simple & Reciprocal versions published - reciprocal gives 0.5Hz ~ 40MHz, at close to 8 digits/s precision )
I looked briefly at the reciprocal version, and to get it to construct the ascii string I'll need to add character literals (or I guess we could use constants like &h20 for space, but that would be ugly; hmmm, come to think of it " "(1) would probably work too).
I think the simple frequency counter should be a trivial port, you'll just need a subroutine to emulate COUNTERA, something like:
sub countera(ctrmode, apin, bpin, freq, phs)
ctra = (ctrmode<<23) or apin or (bpin<<9)
frqa = freq
phsa = phs
end sub
Did you port Bean's Frequency Counters ok ? ( Simple & Reciprocal versions published - reciprocal gives 0.5Hz ~ 40MHz, at close to 8 digits/s precision )
I looked briefly at the reciprocal version, and to get it to construct the ascii string I'll need to add character literals (or I guess we could use constants like &h20 for space, but that would be ugly; hmmm, come to think of it " "(1) would probably work too).
I think the simple frequency counter should be a trivial port, you'll just need a subroutine to emulate COUNTERA, something like:
sub countera(ctrmode, apin, bpin, freq, phs)
ctra = (ctrmode<<23) or apin or (bpin<<9)
frqa = freq
phsa = phs
end sub
Yes, to give a something useful looking emulation result, I thought about
value = phsa
being actually
value = phsa()
and the phsa() function assumes some increment/seconds rate, & on each call it reads PC Timer and scales the dT.
eg suppose we have an expected read rate of 100ms and 455kHz, that should increment 45,000 between calls, so we take the 0.100001234 type timer values,
and multiply by 455k, with maybe some random element added if needed too.
Call it GLUE, or BLISS, or something else descriptive and suggestive.
Then have fun.
Thanks. So far it's still "fastspin BASIC"; I think for now I'll concentrate on the implementation rather than the name. Speaking of which I've uploaded a new version of fastspin with BASIC support (or you can use the [url="http://github.com/totalspectrum/spin2gui/releases]spin2gui[/url] GUI which contains fastspin). This has floating point support (library functions like sin and cos still need to be written, but the basic arithmetic and printing all work), some improved but still incomplete docs, and many improvements to the BASIC compiler, as well as some Spin bug fixes.
I've attached some new demos: a revised fibo() demo which can also compile under FreeBASIC, and a frequency counter demo based closely on Bean's Freq Counter3.pbas.
Do you do your optimizations on the parse tree or on the generated PASM code?
Originally the optimizations were all on the PASM code, but I added some common sub-expression elimination and loop strength reduction on the parse tree, and I'm gradually trying to move some others up to the parse tree as well.
It appears that they changed the behavior of %api.prefix between versions of bison. I hate that kind of thing and I should have avoided the bison specific stuff anyway. The code's updated now so it should work with all bison versions, as well as byacc (although the byacc error messages aren't as nice as bison's, so some of the tests for error messages will fail).
It appears that they changed the behavior of %api.prefix between versions of bison. I hate that kind of thing and I should have avoided the bison specific stuff anyway. The code's updated now so it should work with all bison versions, as well as byacc (although the byacc error messages aren't as nice as bison's, so some of the tests for error messages will fail).
I've updated the spin2cpp/fastspin binaries at https://github.com/totalspectrum/spin2cpp/releases to version 3.9.3. This version has a number of bug fixes (applicable both to Spin and to BASIC) and adds the garbage collecting memory manager. For now the heap is a fixed 256 bytes long, but that will become settable by the user soon. The garbage collector is used for string operations like string concatenation with +, left$, and right$. For example, even though the heap is only 256 bytes long, the following program can run to completion:
function dec$(n as uinteger)
dim digit
if n < 10 then
return chr$(asc("0") + n)
else
digit = n mod 10
n = n / 10
return dec$(n) + chr$(asc("0") + digit)
end if
end function
function greet$(s$)
return "hello, " + s$
end function
dim orig$
dim n as uinteger
orig$ = greet$("world")
print orig$
for n = 1 to 100
print greet$(dec$(n))
next
print orig$
How do you handle the "main" program? It looks like it consists of anything outside of a function definition but does it have to be all together or can you have it interspersed between function definitions?
Comments
From http://mmbasic.com/source.html: The source is not open and (probably) MMBASIC is a one man show. Does that remind someone of BST?
Otherwise it is a nice bag full of features.
I really have no interest in open source...it works or it doesn't. I care about shipping a product that works and rapid development is what I need.
The guy who developed Bypic (Micromite on steroids) just retired but I have the hex file and a PICkit3....it works.
Not a fan of Windows but it helps me get the job done and I get paid....can't make Linux work for me....which one is open source?
I am astounded at the faith that my clients have in myself. I am now a one-man-band with a proprietary product. In many cases, if my product dies, there's a whole bunch of people stood on a factory floor with nothing to do.
In my previous life I shipped enough product in to Big 3 auto that would shut down an entire car production line... We only ever negotiated price, never source code.
http://mmbasic.com/porting.html
http://mmbasic.com/source.html
" Requirements
MMBasic requires a CPU with 32 bit integers and pointers supported by an ANSI or C89 C compiler.
In its minimal version MMBasic typically compiles to about 94K of flash and requires just over 5K of RAM plus a minimum of 4K for the stack (9K total).
More memory is required to store programs, variables, etc so the interpreter will require at least 16K of RAM to run a small BASIC program.
Generally 32K RAM or more is preferred as that will allow for larger programs and arrays.
Keep in mind that adding extra functionality (SD card support, file I/O, etc) will add to these requirements.
Customisation
The language itself is hardware independent. Supporting the language are two main files that will need customisation to suit a particular platform:
Main.c - This is the main entry point and is responsible for configuring the chip, basic character I/O and the main loop which inputs a line and dispatches it to the interpreter.
Memory.c - This allocates RAM for the interpreter's use (program memory, variable memory and the heap).
The configuration of this has been kept flexible so that the language can run on devices with unusual memory mapping.
MMBasic has its own dynamic heap system which is also implemented in this file."
Which all looks pretty nifty, and could even give a path for Parallax to offer module versions, once ported, so that could actually be a nice "Bridge Product"
It's meaty, so be very interesting to see how that .c compiles into P2.
If nothing else, it's a great test pattern for any P2 C Compilers !!!
Ken should be all over this...
http://www.thebackshed.com/forum/forum_posts.asp?TID=10568&PN=2
Picromite (RPi)
http://www.thebackshed.com/forum/forum_posts.asp?TID=9823&KW=Picromite
They also have bigger and faster PICs than the old MX170
Lots more info on the forum and then there's Geoff's site: geoffg.net
https://code.google.com/archive/p/python-on-a-chip/
"Features of the PyMite VM:
Requires roughly 55 KB program memory
Initializes in 4KB RAM; print "hello world" needs 5KB; 8KB is the minimum recommended RAM.
Supports integers, floats, tuples, lists, dicts, functions, modules, classes, generators, decorators and closures
Supports 25 of 29 keywords and 89 of 112 bytecodes from Python 2.6
Can run multiple stackless green threads (round-robin)
Has a mark-sweep garbage collector
Has a hosted interactive prompt for live coding
Licensed under the GNU GPL ver. 2
The PyMite VM DOES NOT HAVE:
A built-in compiler
Any of Python's libraries (no batteries included)
A ready-to-go solution for the beginner (you need to know C and how to work with microcontrollers)
FAQ:
'How much RAM is necessary? A: At least 5 KB to initalize, 8 KB to do something small and more KB if your goals are lofty.
I just built the latest release, why does it fail? A: Please use the latest code from the repository rather than the releases. The release is showing its age and many bugs have been fixed in the repository.
Why does this simple for-loop fail ? for i in range(1, 10000): print i
A: The range() function creates a List with the given number of integers inside it. That list and its contents are consuming all the available RAM. Use xrange() or while() with a counter instead.
Another great C test pattern
Whilst the MMBasic above is looking 'meaty' at ~94kF 5k+4k RAM, for a Basic, it's a natural growth point in MCU space
The PyMite VM at 55kF,4kR starting, looks a nifty parsimonious Python Byte code starting point.
Generic parts like line up nicely here, and that 96kRAM in the LPC51U68, looks good for this type of interpreter payload.
One can look at those numbers, and then look at Chips' highly optimized ByteCode PASM backend in Spin2, a blender, and start to imagine a P2 C/PASM project, that could spit out
a P2 image of a Python Interpreter....
or, take
https://github.com/adafruit/circuitpython/releases
+ highly optimized ByteCode PASM backend
& optimize for speed, might even work..
Dropping a Prop2 release into the https://github.com/adafruit/circuitpython pool would be fun to watch !
I think that this name would be appropriate: guppy - BASIC like compiler. How professional sounding is Python or Perl, or...
This is your creation, so the name is your creation, go for it.
Ray
Did you port Bean's Frequency Counters ok ? ( Simple & Reciprocal versions published - reciprocal gives 0.5Hz ~ 40MHz, at close to 8 digits/s precision )
I'm porting your example from the other thread, to the FreeBASIC/PC
FB gives this
P2_Basic_Fibo_Test.bas(26) error 146: Default types or suffixes are only valid in -lang deprecated or fblite or qb, found ')' in ' function fibo(n)'
P2_Basic_Fibo_Test.bas(27) error 31: Expected 'THEN', found 'return' in 'if (n < 2) return n'
P2_Basic_Fibo_Test.bas(36) error 145: Only valid in -lang deprecated or fblite or qb, found 'let' in 'let start = getcnt()'
P2_Basic_Fibo_Test.bas(38) error 41: Variable not declared, i in 'for i = 1 to 10'
P2_Basic_Fibo_Test.bas(38) error 3: Expected End-of-Line, found ' i' in 'for i = 1 to 10'
P2_Basic_Fibo_Test.bas(40) error 145: Only valid in -lang deprecated or fblite or qb, found 'let' in 'let x = fibo(i)'
P2_Basic_Fibo_Test.bas(42) error 3: Expected End-of-Line, found ' i' in 'print "fibo "; i; " = "; x,'
P2_Basic_Fibo_Test.bas(44) error 14: Expected identifier, found ' i' in 'next i'
but no brickwalls, I'll post the PC results shortly...
Here is the PC port from your P2 code.... - went quite smoothly, and hopefully, this code (with emulation bits trimmed) can eventually compile in your compiler fine ?
I looked briefly at the reciprocal version, and to get it to construct the ascii string I'll need to add character literals (or I guess we could use constants like &h20 for space, but that would be ugly; hmmm, come to think of it " "(1) would probably work too).
I think the simple frequency counter should be a trivial port, you'll just need a subroutine to emulate COUNTERA, something like:
Yes, to give a something useful looking emulation result, I thought about
value = phsa
being actually
value = phsa()
and the phsa() function assumes some increment/seconds rate, & on each call it reads PC Timer and scales the dT.
eg suppose we have an expected read rate of 100ms and 455kHz, that should increment 45,000 between calls, so we take the 0.100001234 type timer values,
and multiply by 455k, with maybe some random element added if needed too.
Then have fun.
Thanks. So far it's still "fastspin BASIC"; I think for now I'll concentrate on the implementation rather than the name. Speaking of which I've uploaded a new version of fastspin with BASIC support (or you can use the [url="http://github.com/totalspectrum/spin2gui/releases]spin2gui[/url] GUI which contains fastspin). This has floating point support (library functions like sin and cos still need to be written, but the basic arithmetic and printing all work), some improved but still incomplete docs, and many improvements to the BASIC compiler, as well as some Spin bug fixes.
There's a basic.md in the fastspin docs/ folder, but it's incomplete.
Either one would work. I think I originally wrote which FreeBASIC didn't like, so I changed it to a multi-line if and didn't bother to put in the else.
(I wanted both demos to compile with FreeBASIC, hence the #ifdefs and dummy stuff for PC support.)
No, both forms generate exactly the same code. There's a branch optimization that gets rid of the unnecessary branch for the "else".
Originally the optimizations were all on the PASM code, but I added some common sub-expression elimination and loop strength reduction on the parse tree, and I'm gradually trying to move some others up to the parse tree as well.
I had the same problem... Turns out that Bison 2.3 on macOS is an old version that does not like the line in spin.y: I had to use homebrew to get a 3.0.4 version of Bison. Homebrew will place it at: You'll then need to mod the Makefile to point to that bison version
dgately
It appears that they changed the behavior of %api.prefix between versions of bison. I hate that kind of thing and I should have avoided the bison specific stuff anyway. The code's updated now so it should work with all bison versions, as well as byacc (although the byacc error messages aren't as nice as bison's, so some of the tests for error messages will fail).