Hi

How can assembler determine that a number is signed or unsigned?

For example this code:

But i cannot do this:

mov ax, cc17h

It gives error.

But why? What is the problem? What is the problem with cc17h?

Thanks

How can assembler determine that a number is signed or unsigned?

For example this code:

mov ax, 9c17h

mov bx, 1209h

add ax, bx

But i cannot do this:

mov ax, cc17h

It gives error.

But why? What is the problem? What is the problem with cc17h?

Thanks

maybe you have to put a zero in front of it.

mov ax,0cc17h

mov ax,0cc17h

Hmm interesting

mov ax, 0xff17

mov bx, 0x1209

add ax, bx

This is woking with emu8086 but not the first one in my first message. I dont understand why it is so.

And also How can assembler determine that a number is signed or unsigned?

Thanks

mov ax, 0xff17

mov bx, 0x1209

add ax, bx

This is woking with emu8086 but not the first one in my first message. I dont understand why it is so.

And also How can assembler determine that a number is signed or unsigned?

Thanks

The only way an assembler might know that a number is signed or unsigned is by the sign flag. This is how programmers determine if a number is signed or unsigned, too. However, you might assume that the sign flag should be set at the 15th bit of a 32-bit DWORD value and still be able to carry on with your calculations but the way that almost all of the programmers/assemblers/compilers do this is through the sign flag which is the leftmost bit of any integral value. I think this will help you understand this concept:

Converting a signed number to an unsigned number:

1) Reverse all bits of the number (for example 1101 will be changed to 0010)

2) Add 1 to the result.

For example if you want to know what the value of +1 is when it is changed to a negative number (-1), simply reverse all of its 32-bits (Assuming 32-bit values are being used) so we have 0x00000001 reversed will be 0xFFFFFFFE. Now as the second step, add 1 to the result so we have 0xFFFFFFFE + 1 = 0xFFFFFFFF. Note that if you are looking at this number as an unsigned number, its value is equal to (2^32)-1 but if it is interpreted as a signed number, it will be equal to -1.

Now if you want to convert from signed to unsigned simply reverse the steps above. So if we have 0xFFFFFFFF (-1), subtract 1 from it to get 0xFFFFFFFE and then reverse its bits to get 0x00000001.

I hope that helps.

Converting a signed number to an unsigned number:

1) Reverse all bits of the number (for example 1101 will be changed to 0010)

2) Add 1 to the result.

For example if you want to know what the value of +1 is when it is changed to a negative number (-1), simply reverse all of its 32-bits (Assuming 32-bit values are being used) so we have 0x00000001 reversed will be 0xFFFFFFFE. Now as the second step, add 1 to the result so we have 0xFFFFFFFE + 1 = 0xFFFFFFFF. Note that if you are looking at this number as an unsigned number, its value is equal to (2^32)-1 but if it is interpreted as a signed number, it will be equal to -1.

Now if you want to convert from signed to unsigned simply reverse the steps above. So if we have 0xFFFFFFFF (-1), subtract 1 from it to get 0xFFFFFFFE and then reverse its bits to get 0x00000001.

I hope that helps.

Thank you very much EXHG

Look at here please

http://www.piclist.com/techref/method/math/c-vs-o.htm

"carry is generally used for unsigned arithmetic and overflow is used for signed arithmetic."

For example 0111 + 1111 = 1 0110

So is this addition signed addition or unsigned addition. I asked this because of that.

Compiler sees 1111, its MSB is 1 but is this signed number or unsigned number?

Thanks again.

Look at here please

http://www.piclist.com/techref/method/math/c-vs-o.htm

"carry is generally used for unsigned arithmetic and overflow is used for signed arithmetic."

For example 0111 + 1111 = 1 0110

So is this addition signed addition or unsigned addition. I asked this because of that.

Compiler sees 1111, its MSB is 1 but is this signed number or unsigned number?

Thanks again.

You are viewing this subject in a bad angle here. Let us say that the most number of bits that our data-bus can handle is 4 so we have 4-bit numbers (whether signed or unsigned). Now if you try to add 1110 + 1010 for example, the ALU computes this addition just like normal binary addition and it wouldn't care if it is signed or unsigned. The only one that has to be worried about it being signed or unsigned is the programmer. So there is no difference between -1 and 1 for the CPU except the fact that 32-bit -1 is shown as 0xFFFFFFFF and 1 is 0x00000001. So if you for example want to calculate -1 + 1 (which results in 0), you will give 0xFFFFFFFF to the CPU and add 0x00000001 to it. (At this point, the CPU just does the addition and it wouldn't care if they are signed or unsigned).

So now you have:

0xFFFFFFFF +

0x00000001 =

-----------

0x00000000 (Carry Flag = 1, Auxiliary flag = 1 although you don't need to worry about the Auxiliary flag).

When the carry flag is set, you have the answer in 32-bit DWORD which is 1. This is just in case you interpreted these values as signed values so that you say 0xFFFFFFFF is -1 and 0x00000001 is 1 but for the CPU 0xFFFFFFFF is equal to (2^32)-1 = 4294967295 = 0xFFFFFFFF. So when you ask the CPU to add 4294967295 (0xFFFFFFFF) and 1 (0x00000001), it will definitely add them as unsigned numbers and it will set the flags accordingly. Now if you interpret the number as a signed value, the carry should mean nothing to you because you were not looking for carry but otherwise it (the carry) tells you that in the process of adding two (unsigned) numbers, the carry flag is set and thus this means that the addition could not be completed in only 32-bits.

I hope that helps. Just look at every number as an unsigned number unless you feel the explicit need to use them as unsigned numbers because the CPU doesn't care.

So now you have:

0xFFFFFFFF +

0x00000001 =

-----------

0x00000000 (Carry Flag = 1, Auxiliary flag = 1 although you don't need to worry about the Auxiliary flag).

When the carry flag is set, you have the answer in 32-bit DWORD which is 1. This is just in case you interpreted these values as signed values so that you say 0xFFFFFFFF is -1 and 0x00000001 is 1 but for the CPU 0xFFFFFFFF is equal to (2^32)-1 = 4294967295 = 0xFFFFFFFF. So when you ask the CPU to add 4294967295 (0xFFFFFFFF) and 1 (0x00000001), it will definitely add them as unsigned numbers and it will set the flags accordingly. Now if you interpret the number as a signed value, the carry should mean nothing to you because you were not looking for carry but otherwise it (the carry) tells you that in the process of adding two (unsigned) numbers, the carry flag is set and thus this means that the addition could not be completed in only 32-bits.

I hope that helps. Just look at every number as an unsigned number unless you feel the explicit need to use them as unsigned numbers because the CPU doesn't care.

XCHG,

The assembler has no cognizance of the sign flag (SF). The CPU does during run time.

A number is never converted from signed to unsigned. It is interpreted as signed or unsigned. The

sawyer,

How does an assembler know that MOV EAX,-3 means load EAX with a negative 3?

Did you not read eek's answer, where he suggested you put a zero in front of a HEX represented number?

You must understand that the compiler does not execute the program, the CPU does. Addition and subtraction use the same instruction for either signed or unsigned operations. The numbers are just intrepreted differently by the application, not the CPU. You really need to look at reply #4 of http://www.masm32.com/board/index.php?topic=2923.0. See also http://www.masm32.com/board/index.php?topic=6620.0

The only way an assembler might know that a number is signed or unsigned is by the sign flag.

The assembler has no cognizance of the sign flag (SF). The CPU does during run time.

Now if you want to convert from signed to unsigned simply reverse the steps above. So if we have 0xFFFFFFFF (-1), subtract 1 from it to get 0xFFFFFFFE and then reverse its bits to get 0x00000001.

A number is never converted from signed to unsigned. It is interpreted as signed or unsigned. The

*sign*of a signed number is sometimes changed. To avoid having to remember whether to subtract or add 1, always flip the bits FIRST, and then always ADD 1, never subtract. This will always work when converting a 2's complement number from positive to a negative or vise versa.sawyer,

How can assembler determine that a number is signed or unsigned?

How does an assembler know that MOV EAX,-3 means load EAX with a negative 3?

But i cannot do this:

mov ax, cc17h

It gives error.

But why? What is the problem? What is the problem with cc17h?

mov ax, cc17h

It gives error.

But why? What is the problem? What is the problem with cc17h?

Did you not read eek's answer, where he suggested you put a zero in front of a HEX represented number?

Compiler sees 1111, its MSB is 1 but is this signed number or unsigned number?

You must understand that the compiler does not execute the program, the CPU does. Addition and subtraction use the same instruction for either signed or unsigned operations. The numbers are just intrepreted differently by the application, not the CPU. You really need to look at reply #4 of http://www.masm32.com/board/index.php?topic=2923.0. See also http://www.masm32.com/board/index.php?topic=6620.0

I really appreciate all the comments. I read them all. I also looked intel's documents. Intels said:

XCHG said

So if CPU doesnt care if it is signed or not why does intel writes signed arithmetic or unsigned arithmetic.

What is the meaning of these cocncepts? What does intel indicate signed artihmetic operation?

Also

@Ratch thanks for links. In that link:

http://www.masm32.com/board/index.php?topic=2923.0 You said

Value2 is : 1111_1111

Why didint you say "Value2 represents -1 signed"

How do you understand it is unsigned.

Thanks for all answers friends...

CF (bit 0) Carry flag ? Set if an arithmetic operation generates a carry or a

borrow out of the most-significant bit of the result; cleared otherwise.This flag indicates an overflow condition for

OF (bit 11) Overflow flag ? Set if the integer result is too large a positive number or too small a negative number (excluding the sign-bit) to fit in the destination operand; cleared otherwise. This flag indicates an overflow condition for

borrow out of the most-significant bit of the result; cleared otherwise.This flag indicates an overflow condition for

**unsigned-integer arithmetic**.OF (bit 11) Overflow flag ? Set if the integer result is too large a positive number or too small a negative number (excluding the sign-bit) to fit in the destination operand; cleared otherwise. This flag indicates an overflow condition for

**signed-integer (two?s complement) arithmetic**.XCHG said

ALU computes this addition just like normal binary addition and it wouldn't care if it is signed or unsigned

So if CPU doesnt care if it is signed or not why does intel writes signed arithmetic or unsigned arithmetic.

What is the meaning of these cocncepts? What does intel indicate signed artihmetic operation?

Also

@Ratch thanks for links. In that link:

http://www.masm32.com/board/index.php?topic=2923.0 You said

Value2 represents 255 unsigned

Value2 is : 1111_1111

Why didint you say "Value2 represents -1 signed"

How do you understand it is unsigned.

Thanks for all answers friends...

sawer,

INTEL is saying that OF AND CF indicates a condition depending on whether the application intreprets the numbers as signed or unsigned. The CPU uses the same ADD and SUB instruction in either case, and does not care whether the number is interpreted as signed or unsigned.

It is 255 unsigned or -1 signed. The same bits are set in either case. It all depends on whether the number is seen as signed or unsigned by the application. Ratch

So if CPU doesnt care if it is signed or not why does intel writes signed arithmetic or unsigned arithmetic.

What is the meaning of these cocncepts? What does intel indicate signed artihmetic operation?

What is the meaning of these cocncepts? What does intel indicate signed artihmetic operation?

INTEL is saying that OF AND CF indicates a condition depending on whether the application intreprets the numbers as signed or unsigned. The CPU uses the same ADD and SUB instruction in either case, and does not care whether the number is interpreted as signed or unsigned.

Value2 is : 1111_1111

Why didint you say "Value2 represents -1 signed"

How do you understand it is unsigned.

Why didint you say "Value2 represents -1 signed"

How do you understand it is unsigned.

It is 255 unsigned or -1 signed. The same bits are set in either case. It all depends on whether the number is seen as signed or unsigned by the application. Ratch

I am laughing myself.Shame! :oops:

OK at last i understand it.

http://teaching.idallen.com/dat2343/00s/overflow.txt

http://www.computing.dcu.ie/~ray/NewCA103/TheFlags.pdf

For every operation CPU adjust CF and OF. But for me:

Thanks friends :thumbsup:

OK at last i understand it.

http://teaching.idallen.com/dat2343/00s/overflow.txt

http://www.computing.dcu.ie/~ray/NewCA103/TheFlags.pdf

For every operation CPU adjust CF and OF. But for me:

NOTE: signed arithmetic OF important : CF irrelevant

NOTE: unsigned arithmetic CF important : OF irrelevant

NOTE: unsigned arithmetic CF important : OF irrelevant

Thanks friends :thumbsup: