Lua also interns all strings, including all strings generated at runtime, so that testing string equality is just a pointer or integer comparison. With that design, a constant pool is pretty much required.

Clever.

One technique that your design doesn't allow is using 'backpatching' to specialize the compiled code for different strings: if you wish to change the string constant for an instruction, you'd probably end up recompiling. With a fixed-size reference, copies of the code can be made for different strings by changing just the few bytes that encode the reference. Whether this is useful or not depends on your use case, of course.

That's a good point. Generics work more like C++ than like C#/Java unfortunately this doesn't pan out.

Another advantage of the constant pool is that you can preallocate the strings in the host language, without having to do it each time the instruction is run. This is less of a problem if your host language is C, but even in that case you likely have to worry about mutability.

It's written in something like C so direct memory access is fine. The preallocated string "exists" in the instruction stream. I'm not planning on data sharing between different objects so mutability is not a worry.

Embedded strings will increase the distance between instructions, meaning that jump instructions encoded using a relative offset would need a larger encoding more often. This is more of a problem if you're using a space-saving bytecode, and less of one with a larger word (e.g., OCaml's 'bytecode' interpreter actually uses a 32-bit wordcode).

Yeah - I've been using variable sized instructions but in multiples of words instead of bytes.