> I am looking for this type of thing for an AT90S1200, but as i have seen
> none prewritten, i think ill have to do the job myself. Everything seems
> like it shouldnt be hard, but how about the branching instructions. I am
> thinking of having a 24C32 SEEPROM hold a series of 16-bit instructions
> (so many bits for the intruction and so many for the argument(s)), but in
> this case id have to have a 11 bit pointer (4096 bytes/2=2^11 locations),
> but that only leaves 5 bits for the command, leaving me only 32 commands
> maximum. Also, what if a command needs two 8-bit arguments?

I have designed a small interpretative language in C for an 8051 project
once.  It supports loops, if/then/else and all the basic stuff you need
to write scripts. But it can be tokenized easy, and the interpreter core
is very small. C-like functions (several arguments, one result) can
be added and used in the script everywhere.

In that language, I used 8 bit tokens. Every command is 8 bits wide.
Additional bytes can be added when required (arguments usually). Some
commands offer storage space in their token, such as

        "STORE TO VAR"  token: b'010xxxxx

It stores something in one of 32 8-bit variables (xxxxx is the index to
the var-memory). What is to be stored is defined in the following byte.
It either is

        another variables content       000xxxxx

        or an 8 bit literal             00100000 xxxxxxxx
        or an 6 bit literal             01xxxxxx

        or one of 128 functions         1xxxxxxx ...
        (...) are 0-N arguments, depending on function

Other stuff can be placed into the 001xxxxx range, such as IO registers.
My script language was really a script language, not a stamp replacement :-)


All those lookups/functioncalls resulted in an 8 bit result, which could
then be stored/added/forwarded to a function/etc. That was the key thing of
the language. It was compact, yet very flexible due to that fact.

Gotos were just another opcode, like
        b'000xxxxx              5 bit relative
        b'001xxxxx xxxxxxxx     13 bit relative

The destination of the last write (usually a var) was remembered. A lot
of commands just accessed that last destination, to save bit space in
the opcode field.  For example the ADD command:

        b'11100000' <value>

evaluates the following value (as above, one or several bytes depending
on type) to an 8 bit result, and ADDs that to the last write destination.

Stuff like      = A +5 - testfunc(3,1);    was encoded to

        CLR A
        ADD literal 5
        SUB function# of testfunc, 3, 1

(7 bytes)

Straigt and easy tokenizer, but a little unfamiliar look (=A instead of A=).

Easy shortcuts such as

        ++;

to increment the last write destination made script writing a convenient
job.