This article sorts out Bits, Bytes and Integers-binary unsigned and Two-complement representations, hexadecimal things.
All data in the computer is composed of binary 0 and 1, directly on the knowledge points.
binary
Unsigned and Two-complement
The same string of binary numbers, if parsed in two different ways, signed or unsigned, will get different values, but the binary number itself remains unchanged. unsigned is unsigned parsing, and two-complement is the most commonly used one in signed parsing.
unsigned
Unsigned is actually the most traditional direct conversion between binary and decimal, directly add bit by bit, and the calculation is over.
For example: for 10110, according to the position of 1, we can know that the values of three 1 are 16+4+2=22 respectively.
For an N-bit unsigned binary number, its binary representation can range from 00...00 to 11...11, that is to say, the range that can be represented is: 0~2^N-1 .
signed（Two-complement）
Two-complement is a common way to interpret signed numbers. In 2's complement representation, the leftmost bit is the sign bit, 1 is a negative number, and 0 is a positive number. The way to make this number negative is that the sign bit also participates in the calculation, making it use a negative weight of the highest bit to make the entire result a negative number.
For example: also for 10110, its value is -16+4+2=-10. Because at this time the leftmost digit becomes a negative number.
In the two's complement representation, there must be 0 padding on the left of the positive number, such as 32 = 0100000 instead of 100000, otherwise it will become a negative number.
How to know -32 according to the binary representation of 32? Formula: -x = ~x + 1
- First of all, we know that 32 under unsigned is 100000;
- Then we add a 0 to the left, which will not affect the size, but a sign bit is given to facilitate subsequent operations, and we get 0100000 at this time;
- Invert all the bits: 1011111, then +1, 1100000 is the -32 we want.
Here comes the problem, this 1100000 is only 7 bits. In a normal computer, if the int type is 32 bits and the long type is 64 bits, how to express -32? It's very simple, just add 1 (as will be mentioned below, the value of the extended sign bit remains unchanged), the int type is -32 bits 11111111 11111111 11111111 11100000. This is the wonderful thing about Two-complement representing negative numbers. Even if the left side is crazy +1, the final result will still not change. If you don’t believe me, you can add it yourself.
Regarding the range of the Two-complement, because the leftmost bit is used as the sign bit, and the left bit is 0 when the number is positive, the overall range is reduced by half. For N-bit binary numbers, the range is: -2^(N-1)~2^(N-1)-1.
UMin, UMax, TMin, TMax
UMin is the smallest under unsigned, which is actually 0; UMax becomes 2 to the Nth power -1 because it is all 1.
TMin is the minimum under Two's Complement, the first digit is 1 (negative number), and the others are all 0, that is, -2 to the N-1 power;
The first bit of TMax is 0 (positive number), and the others are all 1, so the value is 2 to the N-1 power -1.
The above example is posted for the convenience of your understanding when N=16, and the focus should be on various corresponding binary representations.
A special case is added here: -TMin or TMin . First of all, you can easily know that -TMin exceeds the range of Two-complement, because the range of " -2 to the N-1 power of 2 to 2 to the N-1 power -1 " is asymmetrical. But we can calculate the specific reasons step by step:
The last line is the binary representation of -x, and it can be found that it is still TMin.
Type conversion between unsigned and signed
If unsigned and signed are mixed in an expression, signed will be implicitly converted to unsigned , and then the expression will be calculated. In C language, (unsigned) a is to convert a to unsigned, and (int) a is to convert a to signed. Then the expression at this time:
-1 > 0U, is it True or False? Should be True. Note: Here U is an unsigned type.
Use the following picture to explain this example: First, -1 is converted to unsigned type, its binary value remains unchanged, and the value becomes 15, and the unsigned 15 is compared with the unsigned 0, so it is a greater than sign.
Below are some other examples and conclusions related to help you understand this implicit type conversion. In short, first of all, we check whether there are unsigned ones, and if there are any, we will convert them to unsigned ones for processing, and then compare the size. If they are all signed, just compare them directly.
Extension (extension) and Truncation (truncation)
The extension extension is actually to give a number more space. This is very simple. The extension bit does not affect the size of the original number, which is to directly add the sign bit on the left.
In the following example, x is originally a short int type with 2 bytes. After being converted to a 4-byte int type, the binary representation is supplemented with a 2-byte sign bit on the left.
It is simpler to truncate the truncation, just cut off the unnecessary bits on the left. Then reinterpreted according to the results. Regardless of the type, do this, as shown below:
Therefore, the result of truncation is unstable. For example, the data of the sign type is still positive before, but because some parts on the left are removed, the new first sign bit becomes 1, and it directly becomes a negative number.
hexadecimal
The characteristic of hexadecimal is that there are 16 options for each digit range, that is, 0-15, but after 10, it is represented by letters. For hexadecimal, I think a more important point is to know the fast conversion between binary and binary. Here we don't need to use decimal as an intermediate process, just know that one bit in hexadecimal corresponds to half a byte, that is, 4 bits. That is, every 4 bits in binary can be converted into one bit in hexadecimal . like:
0xCAFE = 1100(C) 1010(A) 1111(F) 1110(E)
In this way we can quickly convert between binary and hexadecimal.
There is nothing to say about hexadecimal. Calculating decimal from hexadecimal is similar to calculating decimal from binary, except that the weight of each bit from right to left is 16 to the 0th power, 16 to the 1st power, and 16. Quadratic……
Bitwise operations
Let’s put the very basic part at the end, mainly about & and &&, | and ||, ~ and! The difference is worth mentioning.
First of all, for &, |, ~ and ^ , they are directly calculated for bit by bit 0 and 1 in binary.
And for &&, || and ! , they are aimed at the Boolean value True or False, and the return value can only be True (1) or False (0). When we use concrete data with these symbols, automatic conversions are involved : 0 becomes False, and everything that is not 0 becomes True. Let's take an example: !!3 = 1 . why? Because 3 is not 0, it is True, then !3=False, !!3 is True.
Shift left and right
First of all, you have to know that shifting n bits to the left will multiply the original number by the nth power of 2, and shifting n bits to the right will reduce the nth power of 2 .
For the type of unsigned : whether it is shifted left or right, it will be filled with 0.
For the signed type : For the left shift operation, it is basically to directly add 0 to the right; but for the right shift, it is divided into logical right shift (left complement 0) and arithmetic right shift (left complement sign bit), arithmetic right shift is mainly for negative numbers (The leftmost sign bit bit 1) has the same sign. If it is a positive number, the two right shifts are the same. In general, right-shifting and complementing the sign bit is the most commonly used.
One last thought:
Why do we use two's-complement to represent signed type data? Compared with other representation methods, what is the advantage of this representation? The reasons are as follows:
Other representations of signed integers (ones-complement and sign-and-magnitude) have two representations of zero (+0 and −0), which makes testing for a zero result more difficult. Also, addition and subtraction of two’s complement signed numbers are done exactly the same as addition and subtraction of unsigned numbers (with wraparound on overflow), which means a CPU can use the same hardware and machine instructions for both.
Simply put, the use of two's-complement allows our computer not to care about the actual type of data. For a given binary, the addition and subtraction that should be added and the subtraction can finally get the correct result.
Finally, at the end, a set of cmu official practice questions with answers is attached http://www.cs.cmu.edu/afs/cs/academic/class/15213-m23/www/activities/bits-and-bytes-soln .pdf is used as a supplement, which is convenient for you to deepen your understanding.