This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
haas:fall2023:discrete:projects:blf0 [2024/04/11 16:46] – created 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===== | ||
+ | Much of our experience transacting in numbers on the computer has been with whole number/ | ||
+ | |||
+ | Signed quantities undergo a process known as two's complement, which can be encoded/ | ||
+ | |||
+ | 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===== | ||
+ | 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===== | ||
+ | You will want to go [[/ | ||
+ | |||
+ | * [[/ | ||
+ | |||
+ | {{page> | ||
+ | |||
+ | =====SUBMISSION===== | ||
+ | To be successful in this project, the following criteria (or their equivalent) must be met: | ||
+ | |||
+ | * Project must be submit on time, by the deadline. | ||
+ | * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. | ||
+ | * Executed programs must display in a manner similar to provided output | ||
+ | * output | ||
+ | * Processing must be correct based on input given and output requested | ||
+ | * Output, if applicable, must be correct based on values input | ||
+ | * Code must be nicely and consistently indented | ||
+ | * Code must be consistently written, to strive for readability from having a consistent style throughout | ||
+ | * Code must be commented | ||
+ | * Any "to be implemented" | ||
+ | * these " | ||
+ | * Sufficient | ||
+ | * No global variables (without instructor approval), no goto statements, no calling of main()! | ||
+ | * Track/ | ||
+ | * Submit | ||
+ | |||
+ | ====Submit Tool Usage==== | ||
+ | Let' | ||
+ | submit, you would do the following: | ||
+ | |||
+ | < | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | You should get some sort of confirmation indicating successful submission | ||
+ | if all went according to plan. If not, check for typos and or locational | ||
+ | mismatches. | ||
+ | |||
+ | =====RUBRIC===== | ||
+ | I'll be evaluating the project based on the following criteria: | ||
+ | |||
+ | < | ||
+ | 52: | ||
+ | *: | ||
+ | *: | ||
+ | *: | ||
+ | *: | ||
+ | </ | ||
+ | |||
+ | ===Pertaining to the collaborative authoring of project documentation=== | ||
+ | |||
+ | * each class member is to participate in the contribution of relevant information and formatting of the documentation | ||
+ | * minimal member contributions consist of: | ||
+ | * near the class average edits (a value of at least four productive edits) | ||
+ | * near the average class content change average (a value of at least 1024 bytes (absolute value of data content change)) | ||
+ | * no zero-sum commits (adding in one commit then later removing in its entirety for the sake of satisfying edit requirements) | ||
+ | * adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference | ||
+ | * content contributions will be factored into a documentation coefficient, | ||
+ | * no contributions, | ||
+ | * less than minimum contributions is 0.75 | ||
+ | * met minimum contribution threshold is 1.00 | ||
+ | |||
+ | ===Additionally=== | ||
+ | |||
+ | * Solutions not abiding | ||
+ | * Solutions | ||
+ | * 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 |