bytecode interpreters for tiny computers

Dave Long dave.long at bluewin.ch
Fri Oct 5 06:11:15 EDT 2007


> I've previously come to the conclusion that there's little reason for
> using bytecode in the modern world, except in order to get more
> compact code, for which it can be very effective.  So, what kind of a
> bytecode engine will give you more compact code?

As dc source is its own bytecode, fib in dc (courtesy of Zsbán  
Ambrus) weighs in at 20 bytes:

1dp[pdsd+ldrlxx]dsxx

unfortunately, like SWEET16, dc code blows up quickly after leaving  
its domain.  J is probably the closest equivalent among more modern  
general-purpose languages, and although fib appears to be much longer  
in J (courtesy Marluth @ Everything2), at around 28 bytes:

1:`((],+/@(_2&{.))@$:@<:)@.*

the 8 queens puzzle (which I believe would be very painful in dc;  
Gödel-coding doesn't lend itself to data-structure manipulation) can  
be expressed in only about twice as many bytes[1] (which is still  
smaller than the PowerPC fib -- how's that for density?):

(#~[:(0=>./)[:,/[:([:}.([:i.#)=[:|(]-"1{.))\.|:)(i.A.~[:i.!) 8

-Dave

:: :: ::

[0] for those few who don't have dc, but do have python, see:
http://en.literateprograms.org/Desk_calculator_(Python)

[1] such dense code requires many more bytes of commentary:
http://en.literateprograms.org/Eight_queens_puzzle_%28J%29

> I'm not sure what +* is for, but I'm guessing it was ADDNZ.

It appears to be for implementing each iteration of (Russian/ 
Egyptian/...) Peasant Multiplication.

http://en.wikipedia.org/wiki/Ancient_Egyptian_multiplication
http://www.cut-the-knot.org/Curriculum/Algebra/ 
PeasantMultiplication.shtml

very weakly related: "[FoRK] basic number theory"
http://www.xent.com/pipermail/fork/Week-of-Mon-20060731/042377.html

> ... it should be possible to get a very slow language, with  
> flexibility something like Python's, into maybe 2000-6000 bytes of  
> a microcontroller's ROM.  This should allow you to interactively  
> get out-of-memory errors with great convenience and flexibility.

I have been considering implementing a dc/J-like expression language  
for compiling to smaller AVRs -- I don't tend to have pins free for  
interactive use, but maybe it'd be worth looking into an interpreter  
for the larger AVRs.



More information about the Kragen-discuss mailing list