Hi, can someone tell me if im right in my understanding of how this instruction zeros out the high word of eax, plz understand im new 2 this:

and eax,0FFFFh

eax b4 == 1101000100000100 1111001010001010 (silly made up binary number)

0FFFFh == 0000000000000000 1111111111111111 (the questionable bit)

eax after == 0000000000000000 1111001010001010


Posted on 2002-11-02 23:16:00 by SNDHearn
F in Hex = 15 in decimal.....1 F = a nibble == 4 bits...half a byte

The zeros in 0000FFFF is the high word so if its zero and you "and" it with anything else the result is zero.

When you " and" some register with another..the bits in both registers have to be set in order for the resultant bit to also be set.

Example ........ And 00011000 with 11100111
Result == 00000000

0FFFF ==0000FFFF by the way

Posted on 2002-11-02 23:30:12 by IwasTitan
when you say:

" 0FFFF ==0000FFFF by the way "

are you just saying that the 0's are irelevant or something else?

Posted on 2002-11-03 00:03:07 by SNDHearn
The thing that i don't get is that FFFF is 16 bits only, so where do the extra 0's come from. Maybe im thinking to hard.

Posted on 2002-11-03 00:11:10 by SNDHearn
i think it's just a shorthand thing that MASM recognises

ie. if you were to write
AND eax, ffffh ....an error would be generated

MASM is expecting a 32 - bit value , so it doesn't
like to be given a 16-bit value.

Posted on 2002-11-03 00:20:49 by argus

when you say:

" 0FFFF ==0000FFFF by the way "

are you just saying that the 0's are irelevant or something else?


If i say:

mov eax ,1H

the system or rather aseembler knows that the leading bits are zeros

So in other words if i do this

and eax,0FFFF

it knows because the first operand designates the size of the information

That is eax == 32 bits == 4 bytes == dword
Posted on 2002-11-03 00:35:06 by IwasTitan
hi SNDHearn

If you use: mov EAX,1h

then EAX==00000001h and not 10000000h

so ONE is ONE and 10000000h is 10000000h

Posted on 2002-11-03 03:46:05 by The SharK
There are two reasons for the trailing zeros in hex...

#1 If the first character is alphabetic, then the compiler cannot decide whether it is a variable called Fh, or the number 15...

#2 As with any radix, counting in hex each digit represents the number of base^position in the value, where position starts from zero.
1 in hex = (16^0) * 1 = 1 * 1
11 in hex = ((16^1) * 1) + ((16 ^ 0) * 1) = (16 * 1) + (1 * 1) = 17

The same is true for decimal, except replace 16s with 10s. This means that there are an infinite number of trailing zeros, and the value remains the same, the reason for their inclusion in the textual description of the number is to simplify reading (or in computing to remind you of the bit depth of the assignment).
You should also remember that all 16 bit numbers are a subset of 32bit numbers, so you can assign a number with only the first 16 bits set to a 32 bit register (being unable to would be quite catastrophic :P ).

In the case of boolean bitwise operations it can be useful, as it gives the reader of the code a direct viewable comparison of what is being operated on.

and 0F0F0Fh
= 0C0A08h
; as opposed to
and 0000F0F0Fh
= 0000C0A08h

Which is easier to read?

As for how bitwise operations work, they work in exactly the same way as their boolean couterparts, except they are repeated in parallel across the whole bit range (8, 16, 32, 64, etc.).
so: (treat src, dest, and result as an array of bits)
result[0] = src[0] && dest[0];
result[1] = src[1] && dest[1];
result = src && dest

Posted on 2002-11-03 05:17:18 by Mirno
cheers, so what happens if you try to put something bigger than FFFFFFFF into a 32 bit register, will MASM not assemble it, or does something horrible happen.

Posted on 2002-11-03 22:24:50 by SNDHearn
Hmmmm ..i'm going to try that just to find out. Maybe you should too and answer your own question.


mov ebx, 0FFFFFFFFFh...an extra F


Assembly Error A2084 constant value too large.

There you go.
Posted on 2002-11-03 22:41:09 by IwasTitan
I tried it to, isn't MASM clever.

Posted on 2002-11-03 23:04:40 by SNDHearn
Look at the code below, and decide which is the better way to zero out the upper 16 bits of EAX. Ratch

00000007 0F B7 C0 MOVZX EAX,AX ;3 byte instruction
0000000A 25 0000FFFF AND EAX,0FFFFH ;5 byte instruction
Posted on 2002-11-10 23:27:31 by Ratch

Look at the code below, and decide which is the better way to zero out the upper 16 bits of EAX. Ratch

00000007 0F B7 C0 MOVZX EAX,AX ;3 byte instruction
0000000A 25 0000FFFF AND EAX,0FFFFH ;5 byte instruction

I,m convinced
Posted on 2002-11-11 00:03:38 by IwasTitan
Beware: The partial register stall.

Posted on 2002-11-11 03:49:13 by Mirno
Know of any documentation for the partial register stall? Ratch
Posted on 2002-11-11 07:20:05 by Ratch
Try Agner Fog's Pentium Optimisation found in the help file folder of the MASM
Posted on 2002-11-11 07:41:52 by roticv
Thanks for the reference. But A.F. specifically says the optimizations are for the Pentium. I have a Athalon, so I wonder if those same technicques apply to my CPU. The Pentium and Athalon are functionally the same, but who knows what the differences in implementation are? Ratch
Posted on 2002-11-11 08:23:22 by Ratch
You are correct that the internal architectures are not identical, but they share some comon ideas. As far as I am aware, the Athlon does suffer from partial register stalling, but not under identical circumstances (AMD doesn't release the same level of detail that Intel does).

The basic principal is this:
In order to improve efficiency, registers are no longer a single entity within the chip. Instead there are a series of registers which can be assigned dynamically, due to the dynamic nature, it can be the case that the 16bits of AX are not a part of EAX (until some settling time later when they are re-unified). Quick successive operations on a register and its sub-parts will cause a stall in the pipeling as the processor will not know it has done the wrong thing until after it has done it, at which point it must flush and start again with the correct data.

The exact length of this settling time is not known because AMD do not publish it, not are the special cases known. Intel have a flag to let the unit know that a register is zero, and this is set using (xor/sub) eax, eax - this passes the zero-ness on to the sub-registers and avoids the stall in these cases.

Posted on 2002-11-11 09:07:38 by Mirno
Athlon amd also has more caches on board and also as far as i can see causes windows to use swap filing more.

Been running Athlon amd 1800+ for about a month now and there are certainly some issues with windows.

I guess if your not part of Wintel your not part of Wintel.

Posted on 2002-11-14 20:05:25 by IwasTitan