Differences

This shows you the differences between two versions of the page.

--- haas:fall2019:c4eng:projects:dtr0info [2019/08/23 16:05] – [Hexadecimal as a binary short hand] wedge
+++ haas:fall2019:c4eng:projects:dtr0info [2019/08/25 21:01] (current) – [Declaring variables] wedge
@@ Line 45: / Line 45: @@
 </code>
+=====Naming your source file=====
+Remember to name your source file with a ".c" at the end: **dtr0.c**
+Especially as we will be creating a **dtr0** executable, there will be a naming conflict, and if you are not careful, you may lose your source code if in a separately named file called **dtr0.c**
 =====Binary representation=====
 The computer is a binary device. That means it stores and transacts all its data in base 2, where there are only 2 counting bits: 0 and 1.
@@ Line 144: / Line 148: @@
 Take the number 175 decimal, and say we want to convert it to hexadecimal:
+^  place  ^  value (in decimal)  |
+|  16^0  |  1  |
+|  16^1  |  16  |
+|  16^2  |  256  |
+As we can see, 256 is much larger than 175, so there are ZERO 256s in the number.
+is much larger than 16, and it is next in line, so there are some number of 16s in 175:
+|  0  |  0  |
+|  1  |  16  |
+|  2  |  32  |
+|  3  |  48  |
+|  4  |  64  |
+|  5  |  80  |
+|  6  |  96  |
+|  7  |  112  |
+|  8  |  128  |
+|  9  |  144  |
+|  10  |  160  |
+|  11  |  176  |
+It appears that 10 is our best fit, **there are 10 sixteens** in 175. What is decimal 10 in hex? Looking at our table: 0xA
+- 160 = 15
+We are now down to the one's place. There are 15 ones in 15. What is decimal 15 in hex? Once again, the table says: 0xF.
+Taking the first and second hex value, and concatenating them together, we get: 0xAF.
+Therefore, decimal 175 is hexadecimal AF.
+=====Bitwise AND=====
+The logical AND operation is used to evaluate the true or false nature of two statements (A and B). An AND is true if BOTH A and B are true, and false otherwise.
+A Bitwise-AND (the <nowiki>&</nowiki> operator in C), can be used to perform a bit-by-bit evaluation of two binary values:
+<code>
+     1001
+& 0100   & 0100
+  ====     ====
+     0000
+</code>
+It is a good way of isolating a true value at a certain bit position, and masking out the rest.
+<code c>
+char A  = 13;
+char B  = 4;
+char C  = A & B;
+fprintf (stdout, "A is: 0x%X\n", A);  // %X means "display as hexadecimal"
+fprintf (stdout, "B is: 0x%X\n", B);
+fprintf (stdout, "C is: 0x%X\n", C);
+</code>
+=====Bitwise OR=====
+The logical (inclusive) OR operation is used to evaluate the true or false nature of two statements (A and B). An OR is true if EITHER or BOTH A and B are true, and false otherwise.
+A Bitwise-OR (the <nowiki>|</nowiki> operator in C), can be used to perform a bit-by-bit evaluation of two binary values:
+<code>
+     1000
+| 0100   | 0100
+  ====     ====
+     1100
+</code>
+It is a good way of accumulating desired bits, and ensuring that others are set as desired.
+<code c>
+char A  = 13;
+char B  = 4;
+char C  = A | B;
+fprintf (stdout, "A is: 0x%X\n", A);  // %X means "display as hexadecimal"
+fprintf (stdout, "B is: 0x%X\n", B);
+fprintf (stdout, "C is: 0x%X\n", C);
+</code>
+=====Unsigned values=====
+If we have an unsigned 4-bit value, that means all four bits are dedicated for displaying the value (ranging from 0 to 15, seeing as we have 4 bits). Basically, see the big table above, comparing the binary column against the decimal column.
+=====Signed values=====
+When a signed value is desired, one of the bits is utilized as a so-called "sign bit" (the most-significant, or leftmost, bit of the value).
+It isn't precisely that, however, as we'd end up with a numerical problem (0 is positive, 1 is negative):
+|  0 000  |  +0  |
+|  0 001  |  +1  |
+|  0 010  |  +2  |
+|  0 011  |  +3  |
+|  0 100  |  +4  |
+|  0 101  |  +5  |
+|  0 110  |  +6  |
+|  0 111  |  +7  |
+|  1 000  |  -0  |
+|  1 001  |  -1  |
+|  1 010  |  -2  |
+|  1 011  |  -3  |
+|  1 100  |  -4  |
+|  1 101  |  -5  |
+|  1 110  |  -6  |
+|  1 111  |  -7  |
+Do you see the problem with this approach? We'd end up with TWO zero values: positive zero, and negative zero.
+That sort of breaks the universe in nasty ways.
+So what do we do? Computers have adopted a scheme known as "twos complement" for the encoding of negative values. To obtain the twos complement, we invert the bits, then add one:
+Let's do -1. As +1 is: 0 001, we invert that:
+001 -> 1 110, then add one:
+110 + 1 = 1 111.
+-2: 0 010 -> 1 101 + 1 = 1 110
+-3: 0 011 -> 1 100 + 1 = 1 101
+See a pattern yet? We're going backwards:
+Twos complement:
+|  0 000  |  +0  |
+|  0 001  |  +1  |
+|  0 010  |  +2  |
+|  0 011  |  +3  |
+|  0 100  |  +4  |
+|  0 101  |  +5  |
+|  0 110  |  +6  |
+|  0 111  |  +7  |
+|  1 000  |  -8  |
+|  1 001  |  -7  |
+|  1 010  |  -6  |
+|  1 011  |  -5  |
+|  1 100  |  -4  |
+|  1 101  |  -3  |
+|  1 110  |  -2  |
+|  1 111  |  -1  |
+So now we have values ranging from -8 through +7 (still a quantity of 16).
+Furthermore, due to the "reversal" of the negative values, look how it plays into our arithmetic so naturally:
+<code c>
+signed char number  = 0; // binary 0000
+number  = number - 1;
+fprintf (stdout, "number is: %hhd\n", number);
+number  = 7;  // binary 0111
+number  = number + 1;
+fprintf (stdout, "number is: %hhd\n", number);
+</code>
+So if we had a 4-bit signed variable, and we wanted to ensure it contained the LOWEST possible value, looking at the table, that means we'd want a one in the sign bit, and zeros in all the other bits.
+Is there a way, when we have our signed char number variable, to force it to that state?
+<code c>
+number  = 0;
+number  = number | 0x8;
+</code>
+And for the highest? Would that not be a 0 in the sign bit, followed by all 1s?
+<code c>
+number  = 0;
+number  = number | 0x7;
+</code>

Lab46 Wiki

User Tools

Site Tools

Differences

Page Tools