unsigned/signed in asm

[dl]

Hi

How can i make sure, that an 32-Bit-Value (on a 32-Bit-System) is
unsigned (positive).

As exapmple : 0FFFFFFFFh : How can i make sure, that this is not -1 ?
If i call a function, that allows positive and negative arguments, what
have i to do ?


Here an example:

var dword 0

...

mov var,0FFFFFFFFh

...

push var
call function


or

invoke function,var



As i said, the value has to be positive. In C i just have to cast
"(unsigned)".

And 2nd question: How can i make sure, that the value is negative in the
example above ?





--
Greetings

[Bjarni Juliusson]

On 06/04/2012 11:55 AM, dl wrote:
>
> Hi
>
> How can i make sure, that an 32-Bit-Value (on a 32-Bit-System) is
> unsigned (positive).
>
> As exapmple : 0FFFFFFFFh : How can i make sure, that this is not -1 ?
> If i call a function, that allows positive and negative arguments, what
> have i to do ?

If the function takes signed arguments, then FFFFFFFF is -1 (on a two's
complement computer). To make sure FFFFFFFF is not negative, make sure
the function takes unsigned arguments. You cannot pass values that are
outside the range of the types of the arguments.

> As i said, the value has to be positive. In C i just have to cast
> "(unsigned)".

If the function takes a signed int, then after you have cast your value
to unsigned int it will be cast back to signed int again. The result of
the first cast is the positive value FFFFFFFF, but the result of the
second cast is "implementation-defined or an implementation-defined
signal is raised".


Bjarni
--

INFORMATION WANTS TO BE FREE

[dl]

Thank you. I was in doubt, whether there exist a sort of
"status-register", which determines, whether the operand is signed or not.

--
Greetings

[JJ]

On Mon, 04 Jun 2012 11:55:31 +0200, dl <d...@nospicedham.gmx.de> wrote:
>
>Hi
>
>How can i make sure, that an 32-Bit-Value (on a 32-Bit-System) is
>unsigned (positive).

It's up to the program to decide whether to treat it as signed or
unsigned. That's why there are to kind of instructions for
multiplication and division: DIV & IDIV and MUL & IMUL. Integers at
assembly level is just a storage for any n-bits value.

>As exapmple : 0FFFFFFFFh : How can i make sure, that this is not -1 ?
>If i call a function, that allows positive and negative arguments, what
>have i to do ?

If the function can do do both signed and unsigned, why do you want to
make sure the value is not -1?

>Here an example:
>
>var dword 0
>
>...
>
>mov var,0FFFFFFFFh
>
>...
>
>push var
>call function
>
>
>or
>
>invoke function,var

var can be either positive or negative. When the value is treated as
signed, the highest bit stores the negative flag. 0 is zero or
positive and 1 is negative. If it's a 32-bit integer, bit 31 stores
the sign bit.

>As i said, the value has to be positive. In C i just have to cast
>"(unsigned)".

What if you have a signed 32-bit string to integer function without
range checking and the string is "0xFFFFFFFF"? That would be -1 right?

>And 2nd question: How can i make sure, that the value is negative in the
>example above ?

If the value was converted from a string of "-1", the value would be
0FFFFFFFFh. All compilers that have both signed and unsigned integer
variable types treat them differently. Meaning that the integer type
must be defined prior processing.

[Bjarni Juliusson]

On 06/05/2012 02:58 AM, dl wrote:
> Thank you. I was in doubt, whether there exist a sort of
> "status-register", which determines, whether the operand is signed or not.

Oh I see. No, there is no such thing. Whether a value is signed or
unsigned is defined entirely by the operations you choose to perform on it.

[io_x]

"dl" <d...@nospicedham.gmx.de> ha scritto nel messaggio
news:4fcc8616$0$6635$3ca0...@newsspool2.vodafone-ip.de...

>
> Hi
>
> How can i make sure, that an 32-Bit-Value (on a 32-Bit-System) is
> unsigned (positive).
>
> As exapmple : 0FFFFFFFFh : How can i make sure, that this is not -1 ?
> If i call a function, that allows positive and negative arguments, what
> have i to do ?


> Here an example:
>
> var dword 0
>
> ...
>
> mov var,0FFFFFFFFh
>
> ...
>
> push var
> call function
>
>
> or
>
> invoke function,var

if the function is a C function "int function(int arg)"
than you have to consider var==-1 in the C code
if the function is a C function "int function(unsigned arg)"
than you have to consider var==4294967295 in the C code

in asm it is no matter if var is signed-unsigned
but the matter is the bit are on or off in var and
the x86 instruction apply to it

for some instruction var will be -1 (signed)
for other instruction var will be 4294967295 (unsigned)

[dl]

Thanks for the answers. With this informations I can continue learning
asm :-)


--
Greetings

[wolfgang kern]

"dl" asked:
> Hi

Hello,

> How can i make sure, that an 32-Bit-Value (on a 32-Bit-System) is
> unsigned (positive).

If you talk about x86-CPUs, your question can be answered easy:

The CPU doesn't even know what "signed" may mean ...

> As exapmple : 0FFFFFFFFh : How can i make sure, that this is not -1 ?
> If i call a function, that allows positive and negative arguments, what
> have i to do ?

"Signed Integer" values are only found in High-level languages...

all x86-CPUs work on values (16/32/64 bits) which will rollover and
be truncated to the given size [and here we may think it's signed !]

Only a few x86-CPU instructions work really "signed" ie:
MOVSX reg,val
ADD/ADC...XOR mem/reg,8bit Sign-extextended
MUL reg,imm8
and just a few more in this families...

> Here an example:
>
> var dword 0
>
> ...
>
> mov var,0FFFFFFFFh
>
> ...
>
> push var
> call function

> or

> invoke function,var

Anyway: same as above

> As i said, the value has to be positive. In C i just have to cast
> "(unsigned)".

This is a problem of C here, we ASMers haven't any issues with it.

> And 2nd question: How can i make sure, that the value is negative in the
> example above ?

Negstive values (seen by the CPU) are just additives >0x8000_0000.
The inherent rollover-mechanics will automatically ADD 'signed'
even this 'signed' is a side-effect of rollover.

ie (16-bit): ;similar for 32 and 64-bit code
x:FFF0 jmp +32 ;
which results in FFF0+0020 which is 1_0010 (but all high bit ignored here.
Looks like signed, but it actually isn't :)
it just jumps backwards to x:0010 !

Otherwise we never could branch nor reference anything backwards...

__
wolfgang

[Robert Redelmeier]

wolfgang kern <now...@never.at> wrote in part:
> "dl" asked:

>> How can i make sure, that an 32-Bit-Value (on a 32-Bit-System)
>> is unsigned (positive).
>
> If you talk about x86-CPUs, your question can be answered easy:
> The CPU doesn't even know what "signed" may mean ...

Precisely true, the CPU knows nothing about data. It assumes you
point the instructions at the correct data formats, and will only
rarely complain (eg, NaN if you load the wrong TByte into the FPU)

> Only a few x86-CPU instructions work really "signed" ie:
> MOVSX reg,val
> ADD/ADC...XOR mem/reg,8bit Sign-extextended
> MUL reg,imm8
> and just a few more in this families...

ADC & SBB aren't so much for [un]signed as for multiple
precision (multiword/bignum) math.

ADD/SUB work fine for both signed & unsigned (wraparound is
a feature of twos-complement numbers as wolfgang mentioned).

Apart from [I]MUL & [I]DIV, the biggest distinction around
signed/unsigned done by the CPU is made by the choice of
conditional JMP instructions:

JL / JB ; JLE / JBE ; JG / JA (and others)

the [first] signed version uses the sign flag, the unsigned
version does not. Some conditions look very odd (sign flag
xor ... ) until you learn they are meant to be done after
a SUB or CMP. Compilers are good at this. Many ASM pgmrs
use simpler (unsigned) conditions like JNZ or JC .


-- Robert

[Brent C]

one unmentioned instance the processor uses signs:

short jumps are handled as sign-extended addition...
if sign wasn't extended, the 8-bit value would always jump us forward 0-255
bytes

--
Brent C

"wolfgang kern" <now...@never.at> wrote in message
news:jqteui$ips$1...@newsreader2.utanet.at...