Apparently one time-honored way of generating smaller 6502 code is to add a bytecode VM and implement some functions on the VM. This produces much smaller code which runs slower. One well-known example of this is Wozniak's SWEET16 for the Apple II. People have even written JVMs for the 6502.
I propose that we provide a way of indicating that some functions should be compiled to a VM which we ship as part of the runtime. The VM would only be included if the final image includes functions compiled for it. Based on previous work, a syntactic option would be vmfun, to go with fun and refun, but I could see that getting out of hand.
An additional option that could be included with this is to allow compilation to threaded form, i.e. instead of a bytecode stream, the compiler generates the jumps directly to the subroutines that implement the opcodes. This provides an intermediate size-speed tradeoff between machine code and bytecode. (This doesn't even require an extra target--just a different bytecode assembler.)
Pros:
Allows an avenue for programmers to optimize aggressively for size over speed, if that's what they need.
Removes some pressure on making every single language element maximally 6502-friendly at the cost of usability. (We already do this to some extent, since we support multiplication and division as infix operators, even though they'd actually be a call into the runtime.)
Forces us to make sure that the compiler is retargetable, since we'd effectively have two targets now.
Cons:
Compiler now has to support two targets properly, meaning increased testing surface area.
Understanding compiler output would require additional work.
Questions:
[ ] Are there any features that should be restricted to vmfuns, or should the language be the same regardless of function type?
[ ] Should we provide a way of compiling blocks into bytecode without creating a whole new function? If we do this, do we need a separate function type?
[ ] Do bytecode functions require a different calling convention?
Prior art:
SWEET16 -- A bytecode interpreter by the Woz which was included in the Apple II ROM. Sadly, it's Copyright Apple 1977, and would have been out of copyright by now except for RETROACTIVE COPYRIGHT EXTENSIONS. THANKS DISNEY.
PLASMA -- A language for 6502 with similar goals to ours, actually. Actively developed, and by the same guy who did VM02 (above).
Not really prior art, but David A. Wheeler's 6502 Language Implementation Approaches is full of interesting and useful information. I'd already been considering some of the approaches described, so it's nice to have prior art to build on.
Apparently one time-honored way of generating smaller 6502 code is to add a bytecode VM and implement some functions on the VM. This produces much smaller code which runs slower. One well-known example of this is Wozniak's SWEET16 for the Apple II. People have even written JVMs for the 6502.
I propose that we provide a way of indicating that some functions should be compiled to a VM which we ship as part of the runtime. The VM would only be included if the final image includes functions compiled for it. Based on previous work, a syntactic option would be
vmfun, to go withfunandrefun, but I could see that getting out of hand.An additional option that could be included with this is to allow compilation to threaded form, i.e. instead of a bytecode stream, the compiler generates the jumps directly to the subroutines that implement the opcodes. This provides an intermediate size-speed tradeoff between machine code and bytecode. (This doesn't even require an extra target--just a different bytecode assembler.)
Pros:
Cons:
Questions:
vmfuns, or should the language be the same regardless of function type?Prior art: