Skip to content
Go to file

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time



Note that this is a poorly documented 'project' and it may not have a future. Its usefulness mostly depends on the competition being user-friendly, and they may well be better. Some of the competition being Factor and Forth. They're more standard/more serious projects. (Remember something about factor being able to do C-like performance, wouldn't be surprised.)

Writing this was largely 'inspired' by thinking about sending messages to the arduino, and how linking messages to functions can easily be extended to a somewhat fully fledged language. Further it has a pretty small memory footprint, especially when the evalling and the input part are separated as they are.(and should be..)

One use would be to provide functions that act as trigger for recording stuff on arduino analog inputs in various ways.

Another use is in a Darwinbots-like 'game'. I bet i could do a lot more bots than that implementation seems to be able to..

Memory usage

Atmega assuming 2-byte pointers and ints i count approx 25 bytes, otherwise you pay for what you want:

  • One int per int stack and array, only in use when actually evalling. Guess 64 is a good guess.
  • One pointer per C-function-pointer function.
  • A pointer and the size of the code per stack-language definition.
  • The number of bytes needed for an internal stack-language definition.

If you don't bother with using the stack for something else, and have 10 C-pointer functions and 20 bytes of 'internal stack-language definition', that is about 64+25+20+2*10= 130 bytes.

For instance sqr is def 0 dup * enddef 3 bytes (dup * enddef), the latter depends on how well it allocates.


  • Look at amforth before continuing..

  • Better client side.

    • gdbm-based client does not work yet. And perhaps both definition name/number and code should be stored.
    • NCurses? However, useage from commandline/with pipes must be possible.
  • Documentation.

  • All that shit with dup, drop, swap, over, rot can be a pain in the ass, figure out how real users of stack languages do it? Make clear in documentation to new users how to do that, it is probably main stumbling block.

  • Consider allocating user-definitions differently.

  • Figure out if bitwise stuff with ints can be inconvenient. Work around.

  • Actually implement the floats.

  • For arduino use, the sizes of the types will differ. The client has to be able to deal with it, and we might want to look at what it does on the computer..

  • 'Tool' to help with hard-coded values to make stack-definitions that are already compiled-in.


Everything is under GPLv3, license included under doc/


Jasper den Ouden


simple stack language interpreter



No releases published


No packages published
You can’t perform that action at this time.