一般而言，为了节省内存，又要保证有足够多的operator，字节码被声明为unsigned char类型，因此对于一个虚拟机能够拥有的运算指令只能在255之内。但是有些解释语言为了提高运行效率，却需要更多运算指令来实现内置函数，一旦超过255，unsigned char显然是不够的。
MudOS作为解释LPC语言的虚拟机同样存在这样的问题，它的解决方法如下：
1. 所有operator，efunctions，全部实现为unsigned char。
2. 在opcodes.h中定义所有operator，内置函数的索引。同时定义三个标识宏：BASE，ONEARG_MAX，NUM_OPCODES，从0 ~ (BASE-1)为operator的索引，从BASE ~ (ONEARG_MAX -1)为单参数efunctions的索引，从 ONEARG_MAX ~ NUM_OPCODES为多参数或无参数efunctions的索引。
3. 在operator的前几个声明中有以下宏：F_EFUN0——efunction为0参数, F_EFUN1——efunction为1参数, F_EFUN2——efunction为2参数, F_EFUN3——efunction为3参数, F_EFUNV——efunction的参数个数不定，类似c函数printf。可以在efun_defs.c中找到这些efunction的列表，这个表说明了efunction的函数名，字节码值，参数个数，返回值类型，参数类型，索引值，默认值。
4. 在编译阶段生成字节码时按照如下规则处理operator和efunctions，见i_generate_node函数：
l 如果F_*的索引值小于ONEARG_MAX，则直接以F_*的索引值作为字节码，并存入字节码序列中。
l 如果F_*的索引值大于ONEARG_MAX，且该函数参数个数为n，那么首先存入F_EFUNn的索引值，接着存入F_*的索引值减去ONEARG_MAX的值，构成一个双字节的字节码。
l 如果F_*的索引值大于ONEARG_MAX，且该函数参数个数不定，那么首先存入F_EFUNV的索引值，接着存入实际的参数个数，最后存入F_*的索引值减去ONEARG_MAX的值，构成一个三字节的字节码。
5. 在解释阶段则按照以上字节码的顺序进行解释完成求值过程。
