flat assembler
Message board for the users of flat assembler.
Index
> Main > shr 4 problem, |
Author |
|
Tomasz Grysztar 06 Jul 2006, 15:59
The problem here comes from the fact that when the size of calculated number is word (which is because of DW here), the "not 0FFFFh" is interpreted as 0.
One of the reasons for this is to make things like "DW not 0FFFFh" or "DD not 0FFFFh" work (first makes 0000, second makes FFFF0000) independently on what is the assembler's internal computations size. Thus NOT inside the expression aimed at 16-bit result negates the 16 bits only (unless the number is already larger than 16 bits, but that's another story). To avoid problem you should do it like: Code: dw (MEMDEST and 0ffffh), (MEMDEST and 0f0000h) shr 4 |
|||
06 Jul 2006, 15:59 |
|
lazer1 06 Jul 2006, 16:34
Tomasz Grysztar wrote: The problem here comes from the fact that when the size of calculated number is word (which is because of DW here), the "not 0FFFFh" is interpreted as 0. what are the main scenarios I need to be careful with for this? is it just not + shr or are there other places? I have to check through my code as I often use "not" and "shr", what happens with say "not 00ffffh" ? |
|||
06 Jul 2006, 16:34 |
|
Tomasz Grysztar 06 Jul 2006, 16:37
It's only NOT actually, since it's the only operation that may be able to set some bits higher that all of the set bits in the operands (and for this reason has to be limited to the specified amount of bits).
With the other logical operations, like AND or XOR you wouldn't notice a difference whether it was done this way or not, because if the values fit in 16 bits, after ANDing or XORing they also fit in 16 bits. The whole point here is that when you do a NOT operation, you need to have somehow specified what amount of bits you want to negate. "dw not 1", "dd not 1" and "dq not 1" all declare different values, as NOT operates on different sizes. In the same way "a=word not 1", "a=dword not 1" and "a=qword not 1" all give different values to "a". (One more important thing I forgot to document...) The SHR is not at all related here, it's the "not 0ffffh" in the 16-bit context that gives 0, and thus "MEMDEST and 0" is also just 0. When the shift comes, there's nothing to shift already. "not 00ffffh" is exactly the same as "not 0ffffh", after going through the parser there's no difference. |
|||
06 Jul 2006, 16:37 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.