Aren't there letters in facecodes? And isn't there an integer limit somewhere?
dunde said:I wonder why the facecode operations needs string operands. Why don't they make it with integer operands?
0x0000000000000001124000000020000000000000001c00800000000000000000 = 6724590433320233934322779735076119692987884466761552101376
The_dragon said:dunde said:I wonder why the facecode operations needs string operands. Why don't they make it with integer operands?
Because the face code is by far much much higher than 2 ^ 32 (max int 32).
0x0000000000000001124000000020000000000000001c00800000000000000000 = 6724590433320233934322779735076119692987884466761552101376
dunde said:AFAIK, WB's variables are about 52 bits length.
Actually, they are 64 bits long and all the math ops (val_add, sub, mul..) use 64 bit arithmetic.The_dragon said:dunde said:AFAIK, WB's variables are about 52 bits length.
Warband variables are 32 bits long. Much higher than 32 bits would make the game a little bit slower on 32 bits machines (since it will require some extra cpu cycles just to make a sum (using bignum libraries)).
(assign, reg1, 2147483648),
(display_message, "@2147483648 = {reg1}"), # 2 to pow 31
(assign, reg1, 2147483647),
(display_message, "@2147483647 = {reg1}"), # 2 to pow 31 - 1
(assign, reg1, 4294967296),
(display_message, "@4294967296 = {reg1}"), # 2 to pow 32
(assign, reg1, 4294967295),
(display_message, "@4294967295 = {reg1}"), # 2 to pow 32 - 1
2147483648 = -2147483648
2147483647 = 2147483647
4294967296 = 0
4294967295 = -1
4294967295 = 011111111111111111111111111111111 = -1
4294967296 = 100000000000000000000000000000000 = 0 - that extra bit is not taken into consideration; means that it acts like a 32 bit variable
They are not explicitely converted to 32-bit values, but they use the %d format specifier to print them so the upper 32 bits are effectively ignored.Lav said:Your test will have the same results if 64-bit registers are converted to 32-bit values before being printed.
add ecx, esi
adc eax, [esp+36]
cmpxchg8b said:They are not explicitly converted to 32-bit values, but they use the %d format specifier to print them so the upper 32 bits are effectively ignored.Lav said:Your test will have the same results if 64-bit registers are converted to 32-bit values before being printed.
{reg1}{reg0}
(assign, reg0, 0xFFFFFFFFFF),
(assign, reg1, reg0),
(val_rshift, reg1, 32),
(display_message, "@0xFFFFFFFFFF = 1099511627775 = ({reg1}<<32)|{reg0}"),
("int_to_string", [
(store_script_param, ":very_long_number", 1),
(str_clear, s0),
(assign, ":end", 20), #2 to power 64 has 20 digits, so 20 digits long is the max number
(try_for_range, ":unused", 0, ":end"),
(store_mod, reg1, ":very_long_number", 10),
(val_div, ":very_long_number", 10),
(str_store_string, s0, "@{reg1}{s0}"),
(eq, ":very_long_number", 0),
(assign, ":end", 0),
(try_end),
]),
The_dragon said:Here is a traditionally "mod and divide" script to convert variable to string
Code:("int_to_string", [ (store_script_param, ":very_long_number", 1), (str_clear, s0), (assign, ":end", 20), #2 to power 64 has 20 digits, so 20 digits long is the max number (try_for_range, ":unused", 0, ":end"), (store_mod, reg1, ":very_long_number", 10), (val_div, ":very_long_number", 10), (str_store_string, s0, "@{reg1}{s0}"), (eq, ":very_long_number", 0), (assign, ":end", 0), (try_end), ]),
num = 1234
str = ""
while(num != 0)
{
str = (num % 10) . str
num /= 10
}