lua的虚拟机指令数据是长度为32位(unsigned int或unsigned long)。其中低6位是操作码,接下来8位是参数A,紧接着是9位的参数C,最后是9位的参数B。
那它的格式是BCAop。为什么不是CBAop呢?按字母顺序命名不好吗?
lua的作者roberto是这样解释的:http://lua-users.org/lists/lua-l/2015-05/msg00491.html
下面摘自roberto的回复。
The original order (when we adopted ABC) was ABCOp (from higher to lower bits). Later, we changed it to BCAOp. (So, the current order gives the impression that B and C exchanged places, but it was A who changed.) The reason was only to try to keep the most used fields in the lower bits (because some CPUS take slighly longer to make shifts with larger offsets). So, as A is more used than B or C, we moved it to a lower position. |
I think currently few CPUs have this issue, and probably I do not have access to any of them anyway, so I did not bother to measure. But note that the change in our case was completely neutral in any other aspect (the code is neither more complicated, nor larger, nor anything at all). So, with all other things being completely equal, why not to choose the option that may give you (even with a very low probability) a slight advantage? (If I knew I would have to justify the change, I probably would not have done it, since just the job of explaining it is enough to offset those frail gains :-) |
大家以为是B和C换位置,其实是A和BC换位置了。按作者的说法,是因为想把最常用的数据放在低位,这样某些cpu在做一些位移操作时可以快一点,op和A是最常用的,所以就有了这样一个顺序。
但是其实再把B和C的位置换一换也是可以的啊,C和B两个参数应该是一样的,没有谁更常用一些吧。
可能是因为BC一般被看成是一个整体,所以就变这样了。
如果你喜欢,改一下lua的源码也是可以搞成CBAop这种格式的,而且对效率也没什么很大的影响,基本可以忽略。
作者不也说了嘛:修改这个顺序所带来的回报早就被向大家解释这个顺序所作出的付出抵消了:)