Linked by Thom Holwerda on Fri 25th Aug 2006 09:03 UTC, submitted by anonymous
General Development 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.
Order by: Score:
Bloatware
by JamesW on Fri 25th Aug 2006 11:11 UTC
JamesW
Member since:
2006-03-29

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

Reply Score: 4

RE: Bloatware
by evangs on Sat 26th Aug 2006 19:01 UTC in reply to "Bloatware"
evangs Member since:
2005-07-07

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

Reply Score: 1

Low on memory?
by Invincible Cow on Fri 25th Aug 2006 13:07 UTC
Invincible Cow
Member since:
2006-06-24

If you have memory constraints, why on earth use a scripting language?

Reply Score: 4

RE: Low on memory?
by whartung on Fri 25th Aug 2006 19:04 UTC in reply to "Low on memory?"
whartung Member since:
2005-07-06

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.

Reply Score: 3

Calvin
Member since:
2005-07-14

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.

Reply Score: 3

DoctorPepper Member since:
2005-07-12

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.

Reply Score: 1

Thanks
by Earl Colby pottinger on Fri 25th Aug 2006 16:21 UTC
Earl Colby pottinger
Member since:
2005-07-06

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.

Reply Score: 1

Neat
by snowflake on Fri 25th Aug 2006 16:39 UTC
snowflake
Member since:
2005-07-20

I just donwloaded it, very neat.

Reply Score: 1

Cool
by Sphinx on Fri 25th Aug 2006 17:19 UTC
Sphinx
Member since:
2005-07-09

Is this part of the other os write-up contest thing?

Reply Score: 1

One more thought...
by DoctorPepper on Fri 25th Aug 2006 21:47 UTC
DoctorPepper
Member since:
2005-07-12

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

Reply Score: 2

Forth
by dimosd on Sat 26th Aug 2006 00:22 UTC in reply to "One more thought..."
dimosd Member since:
2006-02-10

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!

Reply Score: 2

Forth - No thanks
by Earl Colby pottinger on Sat 26th Aug 2006 05:34 UTC
Earl Colby pottinger
Member since:
2005-07-06

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.

Reply Score: 2