Adam Dunkels, well-known author of the Contiki operating system and the uIP embedded TCP/IP stack, has written a really small BASIC interpreter called uBASIC in about 700 lines of C code. It is intended to be a very small scripting language for systems where memory really is at a premium such as deeply embedded systems which may have as little as a few hundreds of bytes of RAM. It provides an interesting look into how to write a very lightweight script interpreter.
I use the 25 line dds.c – http://www.ioccc.org/1990/dds.c – from the 1990 ioccc competition for all my BASIC needs.
Also: ‘a very small scripting language for systems where memory really is at a premium’. Didn’t some guys called Gates and Allen do something similar a few years back?
—
10 PRINT “JamesW Rules “;: GOTO 10
My eyes! They burn! Never understood what drove people to submit programs to the IOCCC. Must be have some sadistic streak in them.
The code posted in the original article reminds me of the C interpreter I wrote during my undergraduate years. It’s simple, it’s straight forward, though I imagine BASIC is an easier language to parse than C since you have less overloaded constructs (the operator * for example).
If you have memory constraints, why on earth use a scripting language?
An interpreted language can be very memory efficient, since you can reduce high level operations to a single byte.
Simple example:
PRINT “THIS IS A STRING”
the PRINT gets turned into a token, say 0x25, followed by a 0x10 byte (16, string length) then the characters of the string.
LD HL, STRING_LABEL
JSR PRINT
The interpreter has a 1 byte overhead above the actual data space, whereas in assembly you have a 6 byte overhead.
For a single print statement, the rest of the interpreter is overkill. But for large programs, since the interpreter is a static cost, the cost of the interpreter becomes less and less in terms of the overall size cost of the program.
Not to mention any actual productivity benefits.
No, typically the cost of an interpreter has always been performance, not size.
Just because there are hardware constraints, doesn’t mean the user isn’t time constrained. Sometimes you need a quick an dirty one-time hack that would take a minute to knock out in a high level script.
Thank you for clarifying that. A lot of what I do for work entails “quick and dirty, one-time hacks”. I used to use Perl, but now use Python. I can get more done with Python (or Perl) in 15 minutes, than most programmers can do with C or C++ in a day. Ok, two days.
We are also starting to do more of our project development in Python. There are lots of benefits besides developer time to take into consideration. Readability and maintainability are two biggies. With today’s much higher performance CPUs and tons of memory, the runtime of these “scripts” is no longer an issue like it once was. If your program has to do some massive number crunching, you can write just that part in C, and the rest in Python (or Perl), and have the best of both worlds.
I am downloading it right now. The problem with the versions of interperted Basic that I have right now is that they are so big and complex that I don’t have the time to modify them. A smaller program is just what I need.
Again thanks for the URL and code.
I just donwloaded it, very neat.
Is this part of the other os write-up contest thing?
This takes me back to the early 1980’s, and my introduction to micro-computers (VIC-20, mid-1982). All of the major brands of computer had a built-in BASIC interpreter, and most of them were quite frugal with resource use.
Take the TRS-80 Model 100 (released around 1983). This small “notebook” computer had about 32 KB of programming in ROM, which held all of the built-in applications, including a text editor, address book, scheduler, communications program AND a BASIC interpreter. That was a pretty handy little notebook, and there are lots of them still hanging around.
The BASIC interpreter may not have been the most advanced in the world, but you could do a lot with it. I wrote a simple automobile payment program one Saturday morning, then took the Model 100 with me to the auto dealership that afternoon, and used it to calculate what my payments would be, based on an assumed interest rate and the sticker price of the car. It was pretty darned accurate too!
That was a great time to be in computers! Sometimes simple is good ๐
8-bit home computers with built in Basic. These were the good times ๐
Now about uBasic: If you are looking for a small, trivially portable interpreted language, there’s Forth. More powerful than Basic, most would say. Weirder too.
Used in the 70s and 80s to make the best out of computers with 1KB RAM and a few Khz CPUs.
Nowadays used in BIOS, boot loaders (FreeBSD’s loader and others), embedded and such.
Trivially portable: Most of Forth is written in Forth itself and you only need to implement a few hooks in assembly.
Can act as an OS for itself. Cooperative multitasking, nonetheless! Yet it fits in ROM or a few disk sectors.
Have a look, and have fun!
Forth is one of those lanuages that could be written to be easy to read, but was written to be easy to process instead. That is why I am a Basic/Comal fan.