This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
haas:fall2023:discrete:projects:blf0 [2024/04/11 17:02] – wedge | haas:fall2023:discrete:projects:blf0 [2024/04/12 11:18] (current) – [Process] wedge | ||
---|---|---|---|
Line 7: | Line 7: | ||
=====OBJECTIVE===== | =====OBJECTIVE===== | ||
- | To apply bitwise logic in the application of decoding IEEE754-encoded 32-bit values, displaying the decoded result. | + | To use bitwise logic in the application of decoding IEEE754-encoded 32-bit values, displaying the decoded result. |
+ | |||
+ | =====READING===== | ||
+ | Please consult the following resources to get a better feel on floating point and the IEEE754 standard: | ||
+ | |||
+ | * https:// | ||
+ | * https:// | ||
+ | * [[https:// | ||
+ | * https:// | ||
=====BACKGROUND===== | =====BACKGROUND===== | ||
- | Much of our experience transacting in numbers on the computer has been with integer data. The format for unsigned data is straightforward. | + | Much of our experience transacting in numbers on the computer has been with whole number/integer data. The format for unsigned data is straightforward. |
Signed quantities undergo a process known as two's complement, which can be encoded/ | Signed quantities undergo a process known as two's complement, which can be encoded/ | ||
Line 16: | Line 24: | ||
Floating point data also has an encoding scheme for storage. There are actually a few different floating point standards. One of the common, classic ones frequently found in use is that of IEEE754, which we will focus on in this project. | Floating point data also has an encoding scheme for storage. There are actually a few different floating point standards. One of the common, classic ones frequently found in use is that of IEEE754, which we will focus on in this project. | ||
- | {{: | + | {{: |
+ | |||
+ | ====Process==== | ||
+ | Walking through the decoding scheme, we'll start with an instance of IEEE754-encoded data: **0xC378C000** | ||
+ | |||
+ | The first step is to visualize it in binary so we can proceed to divide it into its distinct components. Doing a simple hexadecimal to binary conversion yields: | ||
+ | |||
+ | ^ C ^ 3 ^ 7 ^ 8 ^ C ^ 0 ^ 0 ^ 0 | | ||
+ | | 1100 | 0011 | 0111 | 1000 | 1100 | 0000 | 0000 | 0000 | | ||
+ | |||
+ | Then, we carve up that 32-bit value according to the IEEE754 standard: | ||
+ | |||
+ | ^ sign (bit 31) ^ exponent (bits 30-23) | ||
+ | | 1 | < | ||
+ | |||
+ | ===Determine the exponent=== | ||
+ | In this example, we have **< | ||
+ | |||
+ | What we do now is take that value, and subtract a **0x7F** from it to get our actual exponent value: | ||
+ | |||
+ | * **0x86-0x7F = +7** | ||
+ | |||
+ | ===Set up our mantissa for exponent processing=== | ||
+ | We then start to setup our whole number value, which conceptually is to the immediate left of the mantissa. We assign a 1 to it by default. As a result, our floating point value (in binary) is currently: | ||
+ | |||
+ | * < | ||
+ | |||
+ | ===bit shift by exponent=== | ||
+ | If our exponent value is positive, we **LEFT SHIFT** by that many bits. If negative, we **RIGHT SHIFT**. | ||
+ | |||
+ | In our case, our exponent value was a +7, so we will **LEFT SHIFT** by 7. Each bit that goes off the left end of the mantissa pops over into the value to the left of the decimal point. | ||
+ | |||
+ | Step-by step, our 24 total bits will progress as follows: | ||
+ | |||
+ | * original: < | ||
+ | * left shift by 1 (1): < | ||
+ | * left shift by 1 (2): < | ||
+ | * left shift by 1 (3): < | ||
+ | * left shift by 1 (4): < | ||
+ | * left shift by 1 (5): < | ||
+ | * left shift by 1 (6): < | ||
+ | * left shift by 1 (7): < | ||
+ | |||
+ | ===determine value to the left of the decimal point=== | ||
+ | The value we have to the left of the decimal point is **< | ||
+ | |||
+ | We prefix the sign to this (1 indicates negative, which in this example it was), so: **-248.** | ||
+ | |||
+ | ===determine the fractional value=== | ||
+ | Now, to get the component to the right of the decimal point, we basically add together the bit positions, which correspond to **1/ | ||
+ | |||
+ | So, with our current value of **< | ||
+ | |||
+ | According to our formula: | ||
+ | |||
+ | * fraction = < | ||
+ | * fraction = < | ||
+ | * fraction = < | ||
+ | |||
+ | As it turns out, < | ||
+ | |||
+ | * fraction = 0 | ||
+ | * fraction = 0 + 0.5 = 0.5 | ||
+ | * fraction = 0.5 + 0.25 = 0.75 | ||
+ | |||
+ | We them put everything together: | ||
+ | |||
+ | * < | ||
+ | Therefore, **0xC378C000** decodes as **-248.75** | ||
=====TASK===== | =====TASK===== | ||
+ | Your task is to write a program that will take in various encoded IEEE754 binary values, and to decode and ultimately display the decoded value. | ||
+ | You will be given a distinct list of floating point values that you will have to decode. | ||
=====EDIT===== | =====EDIT===== | ||
You will want to go [[/ | You will want to go [[/ | ||
Line 62: | Line 140: | ||
< | < | ||
- | 286:blf0:final tally of results (286/286) | + | 52:blf0:final tally of results (52/52) |
- | *:blf0:submitted C and assembly implementations [26/26] | + | *: |
- | *: | + | *: |
- | *: | + | *: |
- | *: | + | *:blf0:provided example worked through |
- | *:blf0:working break on composite optimization [26/26] | + | |
- | *: | + | |
- | *: | + | |
- | *:blf0:all variants and combinations thereof operational [26/26] | + | |
- | *: | + | |
- | *: | + | |
- | *: | + | |
</ | </ | ||
Line 95: | Line 166: | ||
* Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction | * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction | ||
* Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction | * Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction | ||
+ |