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.

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.

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.

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....

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).

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:

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.

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.

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:

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?