This shows you the differences between two versions of the page.
haas:spring2017:unix:projects:irt0 [2017/03/12 16:50] – created wedge | haas:spring2017:unix:projects:irt0 [2017/03/12 17:28] (current) – [Process] wedge | ||
---|---|---|---|
Line 40: | Line 40: | ||
<cli> | <cli> | ||
lab46: | lab46: | ||
- | base 2 | base 8 | base10 | + | base 2 | base 8 | base10 |
----------+----------+----------+---------- | ----------+----------+----------+---------- | ||
0000 | 000 | 0 | 0x00 | 0000 | 000 | 0 | 0x00 | ||
Line 67: | Line 67: | ||
* $3- display signed decimal (with the parameter " | * $3- display signed decimal (with the parameter " | ||
+ | Numerical arguments are to be given in decimal. | ||
+ | |||
+ | If provided, they should adjust the script' | ||
+ | |||
+ | Some additional constraints/ | ||
+ | |||
+ | * octal values MUST have at least 1 leading zero; that is the standard convention for displaying numbers in that base (to help distinguish them from decimal) | ||
+ | * hexadecimal values start with a leading " | ||
+ | * the maximum upper limit you can implement for is 255 (base 10), or **0xFF** hexadecimal. This will keep your output tidy (you' | ||
+ | |||
+ | ====Only specifying starting value==== | ||
+ | In the event only the starting value is specified, assume a count of 16 (so display 16 values, starting at the starting value). Note that for binary and octal, all numbers should be displayed in a block, so if an additional place value comes into the picture, leading zeros must be visible on the preceding values. | ||
+ | |||
+ | For example: | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | base 2 | base 8 | base10 | ||
+ | ----------+----------+----------+---------- | ||
+ | 01100 | 014 | 12 | 0x0C | ||
+ | 01101 | 015 | 13 | 0x0D | ||
+ | 01110 | 016 | 14 | 0x0E | ||
+ | 01111 | 017 | 15 | 0x0F | ||
+ | 10000 | 020 | 16 | 0x10 | ||
+ | 10001 | 021 | 17 | 0x11 | ||
+ | 10010 | 022 | 18 | 0x12 | ||
+ | 10011 | 023 | 19 | 0x13 | ||
+ | 10100 | 024 | 20 | 0x14 | ||
+ | 10101 | 025 | 21 | 0x15 | ||
+ | 10110 | 026 | 22 | 0x16 | ||
+ | 10111 | 027 | 23 | 0x17 | ||
+ | 11000 | 030 | 24 | 0x18 | ||
+ | 11001 | 031 | 25 | 0x19 | ||
+ | 11010 | 032 | 26 | 0x1A | ||
+ | 11011 | 033 | 27 | 0x1B | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | ====Specifying starting and ending value==== | ||
+ | We can adjust the range displayed by specifying an ending value as well: | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | base 2 | base 8 | base10 | ||
+ | ----------+----------+----------+---------- | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | With a specified starting/ | ||
+ | |||
+ | ====Specifying signed column==== | ||
+ | With the word " | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | base 2 | base 8 | base10 | ||
+ | ----------+----------+----------+----------+---------- | ||
+ | 0010 | 002 | 2 | +2 | 0x02 | ||
+ | 0011 | 003 | 3 | +3 | 0x03 | ||
+ | 0100 | 004 | 4 | +4 | 0x04 | ||
+ | 0101 | 005 | 5 | +5 | 0x05 | ||
+ | 0110 | 006 | 6 | +6 | 0x06 | ||
+ | 0111 | 007 | 7 | +7 | 0x07 | ||
+ | 1000 | 010 | 8 | -8 | 0x08 | ||
+ | 1001 | 011 | 9 | -7 | 0x09 | ||
+ | 1010 | 012 | 10 | -6 | 0x0A | ||
+ | 1011 | 013 | 11 | -5 | 0x0B | ||
+ | 1100 | 014 | 12 | -4 | 0x0C | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | Signed values are how the computer represents negative numbers. The convention in common use is to reference the most significant bit (the left-most): if it is a 1, it is considered negative, and 0, it is positive. | ||
+ | |||
+ | The actual process of representing a number as a negative value is known as **two' | ||
+ | |||
+ | For instance, if we had 4-bit values and we wanted to display a 1 as a negative value: | ||
+ | |||
+ | < | ||
+ | | ||
+ | | ||
+ | | ||
+ | ==== | ||
+ | | ||
+ | </ | ||
+ | |||
+ | =====Specifications===== | ||
+ | Evaluation will be based on correctness of values as well as on formatting/ | ||
+ | |||
+ | You'll notice that everything lines up and is positioned similarly: | ||
+ | |||
+ | * each column exists within 8 characters of on-screen real estate, with one addition space padding the left and the right margins of the column. | ||
+ | * The values are right justified with each column, with all bases but decimal being exactly the same length (prepending leading zeroes if necessary) | ||
+ | * The dashes and vertical bars set up an ASCII art-like table pattern that helps make the data more readable. | ||
+ | * You are to manually print out no more than 2 consecutive spaces at a time in your output statements. If you need more, use one of the formatting tools to generate spaces for you. | ||
+ | * Obviously you'll need end results that occupy some sequence of spaces. The distinction I'm making is you're not to do stuff like: **echo " | ||
+ | * I suggest getting cozy with the **printf(1)** tool | ||
+ | * The signed functionality is **optional**; | ||
+ | * You need to check your arguments to ensure they are present and valid. Some examples: | ||
+ | * starting value is a valid (whole) number, and it is greater than or equal to 0 | ||
+ | * ending value is a valid (whole) number, and it is: | ||
+ | * greater than or equal to the starting value, AND | ||
+ | * less than or equal to 255 | ||
+ | * signed third argument is just that, the word, present or not present | ||
+ | * any invalid arguments (invalid number, NOT the word **signed** as an optional third argument), should result in an error message being generated. | ||
=====Submission===== | =====Submission===== | ||
By successfully performing this project, you should have a set of task#.cli files (one for each task). You will want to submit these, along with a **upf1steps** file. | By successfully performing this project, you should have a set of task#.cli files (one for each task). You will want to submit these, along with a **upf1steps** file. |