For a given $op_name (for example, 'cop_label', 'sv_flags', etc...) you get an array ref containing the bytecode number of the op, a reference to the subroutine used to 'PUT' the op argument to the bytecode stream, and the name of the method used to 'GET' op argument from the bytecode stream.

Most ops require one arg, in fact all ops without the PUT/GET_none methods, and the GET and PUT methods are used to en-/decode the arg to binary bytecode. The names are constructed from the GET/PUT prefix and the argument type, such as U8, U16, U32, svindex, opindex, pvindex, ...

Certain SV types are considered 'special'. They're represented by B::SPECIAL and are referred to by a number from the specialsv_list. This array maps that number back to the name of the SV (like 'Nullsv' or '&PL_sv_undef').

For different endian-ness there are ByteLoader converters in effect. Header entry: byteorder.

64int - 64all - 32int is portable. Header entry: ivsize

ITHREADS are unportable. Header entry: archflag - bitflag 1.

TODO For cross-version portability we will try to translate older bytecode ops to the current perl op via ByteLoader::Translate. Asmdata already contains the old ops, all with the PUT method 0. Header entry: perlversion

Bytecode ops: We can only reliably load bytecode from previous versions and promise that from 5.10.0 on future versions will only add new op numbers at the end, but will never replace old opcodes with incompatible arguments. Unsupported insn's are supported by disassemble, and if force in the ByteLoader is set, it is tried to load/set them also, with probably fatal consequences. On the first unknown bytecode op from a future version - added to the end - we will die.

ByteLoader::BcVersions contains logic to translate previous errors from this bytecode policy. E.g. 5.8 violated the 5.6 bytecode order policy and began to juggle it around (similar to parrot), in detail removed various bytecodes, like ldspecsvx:7, xpv_cur, xpv_len, xiv64:26. So in theory it would have been possible to load 5.6 into 5.8 bytecode as the underlying perl pp_code ops didn't change that much, but it is risky.

We have unused tables of all bytecode ops for all version-specific changes to the bytecode table. This only changed with the ByteLoader version, ithreads and major Perl versions.

Also special replacements in the byteloader for all the unsupported ops, like xiv64, cop_arybase.