[HN Gopher] Bytecode interpreters for tiny computers (2007)
___________________________________________________________________
Bytecode interpreters for tiny computers (2007)
Author : mwcampbell
Score : 85 points
Date : 2022-02-21 22:35 UTC (2 days ago)
(HTM) web link (dercuano.github.io)
(TXT) w3m dump (dercuano.github.io)
| benhoyt wrote:
| I had an ideal along these lines a while back that I called
| "nibbleforth": https://github.com/benhoyt/nibbleforth
| karmakaze wrote:
| Cool stuff: 1) Introduction: Density Is King
| (With a Tiny VM) 2) Indirect Threaded 16-bit FORTH: Not
| Great For Density 3) Naive Lisp: Terrible for Density
| 4) Lua's VM: Four-Byte Register-Based Instructions 5) The
| MuP21 and F21 instruction sets 6) Local Variables:
| Registers Or Stacks? 7) Adapting the MuP21 Instruction
| Set to a Smalltalk-Like System 8) Speculative Case Study:
| An F21-like Squeak 9) Steve Wozniak's SWEET 16 Dream
| Machine 10) NanoVM: Java Bytecodes on the AVR 11)
| Code-Compact Data Structures 12) Library Design
| 13) Other Existing Small Interpreters 14) Conclusions:
| Squeak Rules, We Should Be Able To Do Python In A Few K
| buescher wrote:
| Doesn't the SWEET16 make it straightforward to drop in and out
| of straight 6502 machine code? Making it more like a library or
| virtual coprocessor? Did anyone ever target it with a compiler?
|
| Yes, though, cool stuff!
| throwaway81523 wrote:
| Yeah Sweet16 was just a way to get denser code on a 6502, by
| giving you a 16 bit register VM so you could do 16 bit
| operations without having to expand out multiple 8 bit
| instructions. For a compiler target you might be better off
| with bytecode. I remember looking at the sweet16 description
| and thinking it would be hard to compile to, though partly
| because the docs I looked at weren't very complete. It was
| architecturally odd too though.
| teddyh wrote:
| > _With this approach, 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_
|
| Yup. https://sneklang.org/ (Originally created for a machine with
| 32kB of flash and 2kB of RAM.)
| throwaway81523 wrote:
| That is cool, it looks like Python, how did they get it so
| small? Is it garbage collected? Is the interpreter entirely
| resident in the Arduino or does it rely on an external
| communication app hosting the compiler? That approach is
| actually underutilized in my opinion.
|
| I gotta say that AVR Arduino hardware is almost silly by now.
| The Raspberry Pi Pico is probably the successor basic MCU board
| these days. It costs $4 retail, and has a dual ARM M0+ cpu with
| 264KB of ram and 2MB of SPI flash, so it can run Micropython
| and other relatively full featured software.
|
| Also check out my old favorite Hedgehog Lisp:
| https://github.com/sbp/hedgehog
|
| It's a functional-style Lisp dialect whose VM is 20K bytes. It
| uses an external ahead-of-time compiler, no resident
| interpreter.
| rurban wrote:
| Generally AOT compiled code is 10x bigger than a compact and
| flexible bytecode interpreter. Also miles more unsafe. I.e
| micropython is based on Lua, as also microruby and potion,
| just with a proper OO and GC added.
| throwaway81523 wrote:
| The AOT compiled code for Hedgehog is bytecode. I just mean
| that the bytecode compiler is on a PC host rather than
| inside the embedded mcu.
|
| Micropython is completely separate from Lua.
| dang wrote:
| Related:
|
| _Bytecode interpreters for tiny computers_ -
| https://news.ycombinator.com/item?id=2250890 - Feb 2011 (9
| comments)
|
| _Bytecode interpreters for tiny computers (2007)_ -
| https://news.ycombinator.com/item?id=1406981 - June 2010 (8
| comments)
| guessbest wrote:
| I remember the Basic Stamp being incredibly popular in the 90's
| and not being able to get one.
___________________________________________________________________
(page generated 2022-02-23 23:01 UTC)