So the exercise says: "Consider binary encoding of real numbers on 16 bits. Fill the empty points of the binary encoding of the number -0.625 knowing that "1110" stands for the exposant and is minus one "-1"
_ 1110_ _ _ _ _ _ _ _ _ _ _ "
I can't find the answer and I know this is not a hard exercise (at least it doesn't look like a hard one).
Let's ignore the sign for now, and decompose the value 0.625 into (negative) powers of 2:
0.625(dec) = 5 * 0.125 = 5 * 1/8 = 0.101(bin) * 2^0
This should be normalized (value shifted left until there is a one before the decimal point, and exponent adjusted accordingly), so it becomes
0.625(dec) = 1.01(bin) * 2^-1 (or 1.25 * 0.5)
With hidden bit
Assuming you have a hidden bit scenario (meaning that, for normalized values, the top bit is always 1, so it is not stored), this becomes .01 filled up on the right with zero bits, so you get
sign = 1 -- 1 bit
exponent = 1110 -- 4 bits
significand = 0100 0000 000 -- 11 bits
So the bits are:
1 1110 01000000000
Grouped differently:
1111 0010 0000 0000(bin) or F200(hex)
Without hidden bit (i.e. top bit stored)
If there is no hidden bit scenario, it becomes
1 1110 10100000000
or
1111 0101 0000 0000(bin) = F500(hex)
First of all you need to understand that each number "z" can be represented by
z = m * b^e
m = Mantissa, b = bias, e = exponent
So -0.625 could be represented as:
-0.625 * 10^ 0
-6,25 * 10^-1
-62,5 * 10^-2
-0,0625 * 10^ 1
With the IEEE conversion we aim for the normalized floating point number which means there is only one preceding number before the comma (-6,25 * 10^-1)
In binary the single number before the comma will always be a 1, so this number will not be stored.
You're converting into a 16 bit float so you have:
1 Bit sign 5 Bits Exponent 10 Bits mantissa == 16Bits
Since the exponent can be negative and positive (as you've seen above this depends only on the comma shifting) they came up with the so called bias. For 5 bits the bias value is 01 111 == 15(dez) with 14 beeing ^-1 and 16 beeing ^1 ...
Ok enough small talk lets convert your number as an example to show the process of conversion:
Convert the pre-decimal position to binary as always
Multiply the decimal place by 2 if the result is greater 1, subtract 1 and notate 1 if it's smaller 0 notate 0.
Proceed this step until the result is == 0 or you've notated as many numbers as your mantissa has
shift the comma to only one pre-decimal and count the shiftings. if you shifted to the left add the count to the bias if you have to shift to the right subtract the count from the bias. This is your exponent
Dertmine your sign and add all parts together
-0.625
1. 0 to binary == 0
2. 0.625 * 2 = 1.25 ==> -1
0.25 * 2 = 0.5 ==> 0
0.5 * 2 = 1 ==> -1
Abort
3. The intermediary result therefore is -0.101
shift the comma 1 times to the right for a normalized floating point number:
-1.01
exponent = bias + (-1) == 15 - 1 == 14(dez) == 01110(bin)
4. put the parts together, sign = 1(negative), (and remember we do not store the leading 1 of number)
1 01110 01
since we aborted during our mantissa calculation fill the rest of the bits with 0:
1 01110 01 000 000 00
The IEEE 754 standard specifies a binary16 as having the following format:
Sign bit: 1 bit
Exponent width: 5 bits
Significand precision: 11 bits (10 explicitly stored)
Equation = exp(-1, signbit) x exp(2, exponent-15) x (1.significantbits)
Solution is as follows,
-0.625 = -1 x 0.5 x 1.25
significant bits = 25 = 11001
exponent = 14 = 01110
signbit = 1
ans = (1)(01110)(0000011001)
Related
Using 8 bit registers and signed magnitude representation.
I thought 25 in BCD is 010 0101 but my text book says it as 001 1001. Can somebody explain?
25 / 2 = 12r1 (12 with a remainder of 1)
12 / 2 = 6r0 (6 with a remainder of 0)
6 / 2 = 3r0 (3 with a remainder of 0)
3 / 2 = 1r1 (1 with a remainder of 0)
1 / 2 = 0r1 (0 with a remainder of 0)
So 11001 (working backward up the tree) is the binary equivalent to 25.
Another way to think about it is with powers of 2:
(1*16) + (1*8) + (0*4) + (0*2) + (1*1) = 25
And it's worth noting, just as in base 10, leading zeros do not change the value of a number. (00025 == 25) (0011001 == 11001).
The leading zeros are there in your case because your needing to populate an 8 bit register (there needs to be 8 binary digits regardless of their value).
HEX Article
By this I mean,
In a program if I write this:
1111
I mean 15. Likewise, if I write this:
0xF
I also mean 15. I am not entirely sure how the process is carried out through the chip, but I vagely recall something about flagging, but in essence the compiler will calculate
2^3 + 2^2 + 2^1 + 2^0 = 15
Will 0xF be converted to "1111" before this calculation or is it written that somehow HEX F represents 15?
Or simply, 16^0 ? -- which obviously is not 15.
I cannot find any helpful article that states a conversion from HEX to decimal rather than first converting to binary.
Binary(base2) is converted how I did above (2^n .. etc). How is HEX(base16) converted? Is there an associated system, like base 2, for base 16?
I found in an article:
0x1234 = 1 * 16^3 + 2 * 16^2 + 3 * 16^1 + 4 * 16^0 = 4660
But, what if the number was 0xF, does this represent F in the 0th bit? I cannot find a straightforward example.
There are sixteen hexadecimal digits, 0 through 9 and A through F.
Digits 0 through 9 are the same in hex and in decimal.
0xA is 1010.
0xB is 1110.
0xC is 1210.
0xD is 1310.
0xE is 1410.
0xF is 1510.
For example:
0xA34F = 10 * 163 + 3 * 162 + 4 * 161 + 15 * 160
This more of a hw question but I cannot figure this one out. I thought it would be 214 but because of the first bit on the left, I am not so sure.
As it's a 2's complement number, the first bit being one means that it's a negative number.
The value is 214 - 256 = -42.
It can also be calculated as -(~214 + 1) = -(41 + 1) = -42.
Binary that would be -(~11010110 + 1) = -(00101001 + 1) = -00101010.
the translation is simple:
1: substract 1 from x
11010110-00000001=11010101
2: invert it
00101010
3: calculate binary to dec (but ignore first bit)
2+8+32 = 42
4: remember the first bit of original value ( == 1)
if 1 => invert it => -42
You can tell it's a negative number since there's a 1 in the leftmost bit position. One way you can get the magnitude is invert all the bits and then add 1.
11010110
00101001 <= inverted
00101010 <= +1
This result is decimal 42, so the original value is representing -42.
What are w-bit words in computer architecture ?
For two 7 bit words
1011001 = A
1101011 = B , how does multiplication returns
10010100110011 ?
Isn't there simple binary multiplication involved in these ?
Please provide an example.
w-bit is just the typical nomenclature for n-bit because w is usually short for word size
Both adding and multiplying are done just the same as in decimal (base 10). You just need to remember this truth table:
Multiplying
-----------
0 x 0 = 0
0 x 1 = 0
1 x 0 = 0
1 x 1 = 1
Adding
-----------
0 + 0 = 0
0 + 1 = 1
1 + 0 = 1
1 + 1 = 0 (w/ carry)
First adding. To add, you add just like you would in normal arithmetic, except follow the truth table above:
00000101 = 5
+ 00000011 = 3
--------------
00001000 = 8
How this works is that you start from the right and work left. 1 + 1 = 0, but you carry a 1 over to the next column. So the next column is 0 + 1, which would be 1, but since you carried another 1 from the previous column, its really 1 + 1, which is 0. You carry a 1 over the next column, which is 1 + 0, but really 1 + 1 because of the carry. So 0 again and finally move the 1 to the next column, which is 0 + 0, but because of our carry, becomes 1 + 0, which is 1. So our answer is 1000, which is 8 in decimal. 5 + 3 = 8, so we know we are right.
Next, multiplying:
00000101 = 5
x 00000011 = 3
----------
101 = 5
+ 1010 = 10
----------
1111 = 15
How this works is you multiply the top number 00000101 by the right most digit in the second row. So 00000011 is our second row and 1 is the right most digit, so 00000101 times 1 = 101. Next you put a 0 placeholder in the right most column below it, just like in normal multiplication. Then you multiply our top original number 00000101 by the next digit going left in our original problem 00000011. Again it produce 101. Next you simply add 101 + 1010 = 1111 ...That is the answer
Yes, it's simple binary multiplication:
>>> 0b1011001
89
>>> chr(_)
'Y'
>>> 0b1101011
107
>>> chr(_)
'k'
>>> ord('Y') * ord('k')
9523
>>> bin(_)
'0b10010100110011'
If you want to multiply, you simply do the multiplication the same as with decimal numbers, except that you have to add the carries in binary:
1011001
x1101011
-------
1011001
1011001.
0000000..
1011001...
0000000....
1011001.....
1011001......
--------------
10010100110011
w-bit words aren't anything by themselves. Assuming that the value of w has been previously defined in the context in which "w-bit word" is used, then it simply means a word that is composed of w bits. For instance:
A version of RC6 is more accurately specified as RC6-w/r/b where the word size
is "w" bits, encryption consists of a nonnegative number of rounds "r," and
"b" denotes the length of the encryption key in bytes. Since the AES
submission is targetted at w=32, and r=20, we shall use RC6 as shorthand to
refers to such versions.
So in the context of that document, a "w-bit word" is just a 32-bit value.
As for your multiplication, I'm not sure what you are asking. Google confirms the result as correct:
1011001 * 1101011 = 10010100110011
How can I do division by 2 in Binary Signed digit (Redundant Binary representation) ? Shifting won't work right ?
A redundant binary representation is just an expression of the form:
\sum_{i=0}^n d_i 2^n
where the d_i's are drawn from a larger set than just {0,1}.
Dividing by two or shifting right takes that to
\sum_{i=0}^{n-1} d_{i+1} 2^n + f(d_0)
The trick comes in how to deal with adjusting for the redundant representation for d_0.
If your RBR has digits the form {0,1,2} and has a 2 for the least significant digit you will then have to add 1 to the result to compensate, so f(0) = 0, f(1) = 0, f(2) = 1 should work.
4 = 12_base2, so 12_base2 >> 1 = 1 + f(2) = 1 + 1 = 2_base2 = 2 as expected.
6 = 102_base2, so 102_base2 >> 1 = 10_base2 + f(2) = 11_base2 = 3
You can get something similar for signed redundant binary representations (i.e. with d_i in {-1,0,1}) by setting f(-1) = -1.
1 = 1(-1)_base2, so 1(-1)_base2 >> 1 = 1 + f(-1) = 1 - 1 = 0
So ultimately the naive approach of just shifting does work, you just need a fudge factor to account for any redundant encoding of the shifted digits.
If your chosen RBR includes more options, you'll need to adjust the fudge factor accordingly.