>> Not sure how well it works for very large tables where we risk bumping
>> into the 32K limit of bytecode jumps.
> That did occur to me.
> Perhaps one way to address that limitation without completely
> overhauling the VM would be to introduce a form of segmented memory
> for byte strings.
IIRC the limitation is only in the size of relative jumps, so we might
be able to fix it just by adding a new "longbranch" instruction,
The issue there is that (IIRC) the relative branch opcodes haven't been used since v20, and are marked as obsolete/slated for removal. So, the compiler would have to be altered to use long branches initially, with some later phase replacing them with either relative or short absolute branch codes currently emitted if applicable. The trampoline extension wouldn't require alterations to any construct that is already correctly compiled.
The other potential bonus of the trampoline approach is that it could be used to "link" byte code vectors at some point in the future or provide a form of compilation unit for byte-code.
Lynn