English
资源说明：simple stack language interpreter
# Stackmatic
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](http://factorcode.org/) 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](http://wiki.darwinbots.com/w/Main_Page)-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.
## TODO
* Look at [amforth](http://amforth.sourceforge.net/) before continuing..
* Better client side.
* [gdbm](http://www.gnu.org.ua/software/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.
## Copyright
Everything is under GPLv3, license included under `doc/`
## Author
Jasper den Ouden
本源码包内暂不包含可直接显示的源代码文件，请下载源码包。
