Message board for the users of flat assembler.
> Compiler Internals > Fasm optimization question about expression calculating
Well, Fasm calculates bot the "AND" and "OR" numerical operators like that:
calculate_and: mov eax,[edi] and [ebx],eax mov eax,[edi+4] and [ebx+4],eax jmp calculation_loop calculate_or: mov eax,[edi] or [ebx],eax mov eax,[edi+4] or [ebx+4],eax jmp calculation_loop
That was rather simple and as expected. But can someone explain why "XOR" (also "NOT") need such a complicated crap? :
calculate_xor: cmp [value_size],1 je xor_byte cmp [value_size],2 je xor_word cmp [value_size],4 je xor_dword cmp [value_size],6 je xor_pword xor_qword: mov eax,[edi] xor [ebx],eax mov eax,[edi+4] xor [ebx+4],eax jmp calculation_loop xor_byte: mov eax,[edi+4] or eax,[ebx+4] jnz xor_qword mov eax,[edi] or eax,[ebx] and eax,not 0FFh jnz xor_qword mov al,[edi] xor [ebx],al jmp calculation_loop xor_word: mov eax,[edi+4] or eax,[ebx+4] jnz xor_qword mov ax,[edi+2] or ax,[ebx+2] jnz xor_qword mov ax,[edi] xor [ebx],ax jmp calculation_loop xor_dword: mov eax,[edi+4] or eax,[ebx+4] jnz xor_qword mov eax,[edi] xor [ebx],eax jmp calculation_loop xor_pword: mov ax,[edi+6] or ax,[ebx+6] jnz xor_qword mov eax,[edi] xor [ebx],eax mov ax,[edi+4] xor [ebx+4],ax jmp calculation_loop
Apparently, it is checking the operand size by testing how much of the upper bits are set/zero. But then, why doesn't "AND" and "OR" need such a thing?
Please help Privalov, or Tomasz Grysztar? (I just see you put your real name in, maybe I should do so also ?) )
MCD - the inevitable return of the Mad Computer Doggy
|27 Jun 2005, 12:21||
All values are stored internally as 64-bit signed values, and when they have to be assigned to some specific task that needs the value of smaller size (like definition of the data byte), the value is checked to fit in the range of that smaller size. However the both signed and unsigned ranges are allowed, so you can define bytes from -128 up to 255. And so when you write:
the -1 is stored internally as 0FFFFFFFFFFFFFFFFh (signed 64-bit value) and then converted into signed byte 0FFh. And when you write:
it is stored internally as 0FFh in 64 bits, and then cut down to unsigned byte.
Now when you write:
db not 255
from the context fasm assumes you mean negating the byte value. However if it just negated the full 64 bit value on which it operates, the result would be 0FFFFFFFFFFFFFF00h, which is the negative value that doesn't even fit into byte. For this reason there is the special handling of NOT.
However I've just noticed that for XOR the above code is completely unecessary, as it does anyway exactly the same as if straightforward XORing was done. I should change it to the simple one.
|27 Jun 2005, 14:19||
< Last Thread | Next Thread >
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.