I’m planning an experiment to change the CS bootstrap: add a portable bytecode backend to Chez Scheme, where the bytecode is interpreted and similar to machine code, but using an even simpler encoding to cover the handful of instructions that we need.

If I guess correctly that interpreting bytecode is 5–10 times as slow as machine code, then it will provide a simpler and faster way to build Chez Scheme. We’d have to check bytecode boot files into the ChezScheme repo, and also check in schemified thread, io, regexp, expander, and schemify layers in the racket repo. But then CS would build without building BC, although the old bootstrap path can remain as a fallback (because bootstrapping Chez Scheme with Chez Scheme is painful after certain kinds of changes).

If I guess wrong and bytecode is 100 times as slow, then this idea probably won’t work.

Why would you need the bytecode versions of the Racket layers? Wouldn’t the schemified s-expressions be sufficient, since you’d go bytecode chez -> regular chez -> racketcs (using the s-exps)?

I also like this idea because it seems like a good target for compiling to JS/Wasm

Right: no bytecode for the Racket layers, just the schemified form.

Oh yes, I now see that’s what you wrote.

Currently Chez compiles the boot files to machine code. So the idea is to have a machine independent bytecode that you checkin to avoid generating the machine files. Then the bytecode interpreter, written in Chez. uses those bytecode boot files to bootstrap itself to machine code bootfiles. Thus avoiding using racket during the bootstrap. Did I make sense?

Yes, that’s right.

Well, a clarification: the bytecode interpreter (as opposed to compiler) will be implemented in C and part of the Chez Scheme kernel, so you can get it running using just a C compiler. I expect it to be very small, though.

Nice! :slightly_smiling_face: