twos-complement

Consider the following code, which is an SSCCE of my actual problem: #include <iostream> int roundtrip(int x) { return int(float(x)); } int main() { int a = 2147483583; int b = 2147483584; std::cout << a << " -> " << roundtrip(a) << '\n'; std::cout << b << " -> " << roundtrip(b) << '\n'; } The output on my computer (Xubuntu 12.04.3 LTS) is: 2147483583 -> 2147483520 2147483584 -> -2147483648 Note how the positive number b ends up negative after the roundtrip. Is this behavior well-specified? I would have expected int-to-float round-tripping to at least preserve the sign correctly... Hm, on

The manpage says about memset : #include <string.h> void *memset(void *s, int c, size_t n) The memset() function fills the first n bytes of the memory area pointed to by s with the constant byte c . It is obvious that memset can't be used to initialize int array as shown below: int a[10]; memset(a, 1, sizeof(a)); it is because int is represented by 4 bytes (say) and one can not get the desired value for the integers in array a . But I often see the programmers use memset to set the int array elements to either 0 or -1 . int a[10]; int b[10]; memset(a, 0, sizeof(a)); memset(b, -1, sizeof(b));

I read Why is the range of bytes -128 to 127 in Java? it says 128 is 10000000. Inverted, it's 01111111, and adding one gets 10000000 again so it concludes -128 is 10000000 so +128 cannot be represented in 2's complement in 8 bits, but that means we can represent it in 9 bits, so 128 is 010000000 and so taking its 2's complement -128 is 110000000, so is representation of -128 10000000 or 110000000 ? Is the representaion bit dependent ? Why not simply make the lower range -127 fot 8 bits instead of writing -128 as 10000000 ? Why is the range of unsigned byte is from -128 to 127? It's not. An

This is most probably the dumbest question anyone would ask, but regardless I hope I will find a clear answer for this. My question is - How is an integer stored in computer memory? In c# an integer is of size 32 bit. MSDN says we can store numbers from -2,147,483,648 to 2,147,483,647 inside an integer variable. As per my understanding a bit can store only 2 values i.e 0 & 1. If I can store only 0 or 1 in a bit, how will I be able to store numbers 2 to 9 inside a bit? More precisely, say I have this code int x = 5 ; How will this be represented in memory or in other words how is 5 converted

Im having some trouble understanding how and why this code works the way it does. My partner in this assignment finished this part and I cant get ahold of him to find out how and why this works. I've tried a few different things to understand it, but any help would be much appreciated. This code is using 2's complement and a 32-bit representation. /* * fitsBits - return 1 if x can be represented as an * n-bit, two's complement integer. * 1 <= n <= 32 * Examples: fitsBits(5,3) = 0, fitsBits(-4,3) = 1 * Legal ops: ! ~ & ^ | + << >> * Max ops: 15 * Rating: 2 */ int fitsBits(int x, int n) { int r,

I have a hex string that represents a 2's complement number. Is there an easy way (libraries/functions) to translate the hex into a decimal without working directly with its bits?? E.G. This is the expected output given the hex on the left: "0000" => 0 "7FFF" => 32767 (max positive number) "8000" => -32768 (max negative number) "FFFF" => -1 Thanks! This seems to trick java into converting the number without forcing a positive result: Integer.valueOf("FFFF",16).shortValue(); // evaluates to -1 (short) Of course this sort of thing only works for 8, 16, 32, and 64-bit 2's complement: Short

The Intel Software Development Manual says this about the neg instruction: The CF flag set to 0 if the source operand is 0; otherwise it is set to 1. The OF, SF, ZF, AF, and PF flags are set according to the result. I thought that AF and CF would be set as if neg %eax were replaced by, not %eax # bitwise negation add $1, %eax But that's not the case, negating 0x6ffffef5 on a real CPU sets AF and CF. neg sets all flags identically to what you'd get with a sub from 0. This sequence of instructions sets all flags (including AF and CF) identically to neg %eax : xor %ecx, %ecx sub %eax, %ecx # ecx

I'm trying to wrap my head around overflow & carry flags in x86. As I understand it, for addition of signed 2's complement numbers, the flags can only be generated in one of four ways (my examples are 4-bit numbers): pos+pos = neg (overflow) 0111 + 0001 = 1000 (7 + 1 = -8) pos+neg = pos (carry) 0011 + 1110 = 0001 (3 + -2 = 1) neg+neg = neg (carry) 1111 + 1111 = 1110 (-1 + -1 = -2) neg+neg = pos (overflow & carry) 1000 + 1001 = 0001 (-8 + -7 = 1) So, in x86 assembly, does subracting B from A generate the same flags as adding A and -B? Here's a reference table that might help. This shows an