09.07.2012, 13:12
It seems to have to do with the number of unique opcodes used, or at least I suspect so.
The values on Linux are absolute pointers, though it gets even more mysterious here.. I collected a few values that the opcode values pointed to, reversed the byte order, and came up with this:
Look at ALIGN.alt/ALIGN.pri! While their pointers were different, they pointed to the same values (perhaps some sort of struct with the same info in the beginning, who knows).
(the lines that are grouped are next to each other in amx.h).
The values on Linux are absolute pointers, though it gets even more mysterious here.. I collected a few values that the opcode values pointed to, reversed the byte order, and came up with this:
Look at ALIGN.alt/ALIGN.pri! While their pointers were different, they pointed to the same values (perhaps some sort of struct with the same info in the beginning, who knows).
(the lines that are grouped are next to each other in amx.h).
Код:
/* Values for opcodes: ADD - 0x8B55C089 - 0b10001011010101011100000010001001 ADD.C - 0x8B168D46 - 0b10001011000101101000110101000110 ADDR.alt - 0x8B55C08D - 0b10001011010101011100000010001101 ADDR.pri - 0x8B4DC08D - 0b10001011010011011100000010001101 ALIGN.alt - 0x8B0683C6 - 0b10001011000001101000001111000110 ALIGN.pri - 0x8B0683C6 - 0b10001011000001101000001111000110 JZER - 0x8B45E485 - 0b10001011010001011110010010000101 LCTRL - 0x833E068D - 0b10000011001111100000011010001101 MOVE.alt - 0x8B4DE489 - 0b10001011010011011110010010001001 MOVE.pri - 0x8B55C089 - 0b10001011010101011100000010001001 MOVS - 0x8B45E48B - 0b10001011010001011110010010001011 NEG - 0x8B4DC089 - 0b10001011010011011100000010001001 NEQ - 0x8B4DBC31 - 0b10001011010011011011110000110001 NOP - 0x8B7DC089 - 0b10001011011111011100000010001001 PUSH.alt - 0x8B45BC8D - 0b10001011010001011011110010001101 PUSH.pri - 0x8B45E48D - 0b10001011010001011110010010001101 */