231 Fall 2009 - Program 3 Assignment (this file can be found in /home/mark/public_html/231/f09.program3) Due date: Tuesday, Nov. 3, by midnight Grading standard: correctness - 80% of grade header documentation - 20% of grade Submission: handin.231.1 3 atob.m Tools needed: editor of your choice m4 macro processor gcc on SPARC system Concepts needed: SPARC assembly language passing parameters via SPARC registers interfacing with a C calling program ldb and stb for handling character strings Write three SPARC subroutines named "atob", "btoa", and "bto32a" to provide ASCII to/from binary conversions. These subroutines will have interfaces similar to the standard C library routines atoi() and itoa(). All three subroutines should be placed together into one source file named "atob.m". /* ascii-to-binary * * input parameter - pointer to string * * return value - binary value when string interpreted as * set of binary digits * * atoi()-like interface: * - stops on first ascii character that cannot be converted * (i.e., first character that is not a '0' or '1') * - overflow is not checked (i.e., only the last 32 characters in * the input string are significant in cases with more than 32) */ unsigned atob( char *s ); /* binary-to-ascii * * input parameters - 32-bit binary value * - pointer to string in which routines deposits * converted characters; the memory allocated * for the string must have space for at least * 33 characters * * effect is to change memory contents of string * * btoa variant ignores leading zeros, but will convert to "0" as * ACSII character string for an input value of zero * bto32a variant inserts leading zeros for 32 printable characters * * itoa()-like interface */ void btoa( unsigned value, char *s ); void bto32a( unsigned value, char *s ); The following C program can be used as a test driver. m4 atob.m > atob.s gcc driver.c atob.s ---- #include #include unsigned atob( char *s ); void btoa( unsigned value, char *s ); void bto32a( unsigned value, char *s ); char s[10][40]; int main(){ int i; unsigned v; char r[40]; strcpy(s[0],"0"); strcpy(s[1],"1"); strcpy(s[2],"10111011111111111111111111111101"); strcpy(s[3],"1011101111111111111111111111110100"); strcpy(s[4],"101"); strcpy(s[5],"0101"); strcpy(s[6]," 0101"); strcpy(s[7],"012101"); strcpy(s[8],"-1"); strcpy(s[9],"abcd"); printf("\n"); for( i = 0; i < 10 ; i++ ){ v = atob(s[i]); printf("\"%s\" is 0x%08x\n",s[i],v); btoa(v,r); printf(" reconverted by btoa() and bto32a() is\n\"%s\" and\n",r); bto32a(v,r); printf("\"%s\"\n\n",r); } return 0; } ---- When run, it prints: ---- "0" is 0x00000000 reconverted by btoa() and bto32a() is "0" and "00000000000000000000000000000000" "1" is 0x00000001 reconverted by btoa() and bto32a() is "1" and "00000000000000000000000000000001" "10111011111111111111111111111101" is 0xbbfffffd reconverted by btoa() and bto32a() is "10111011111111111111111111111101" and "10111011111111111111111111111101" "1011101111111111111111111111110100" is 0xeffffff4 reconverted by btoa() and bto32a() is "11101111111111111111111111110100" and "11101111111111111111111111110100" "101" is 0x00000005 reconverted by btoa() and bto32a() is "101" and "00000000000000000000000000000101" "0101" is 0x00000005 reconverted by btoa() and bto32a() is "101" and "00000000000000000000000000000101" " 0101" is 0x00000000 reconverted by btoa() and bto32a() is "0" and "00000000000000000000000000000000" "012101" is 0x00000001 reconverted by btoa() and bto32a() is "1" and "00000000000000000000000000000001" "-1" is 0x00000000 reconverted by btoa() and bto32a() is "0" and "00000000000000000000000000000000" "abcd" is 0x00000000 reconverted by btoa() and bto32a() is "0" and "00000000000000000000000000000000" ---- Programming Note: In approaching this program assignment as well as other assembly language assignments, the use of gcc -S is allowed (and even to a degree encouraged). However, it should be a pathway to learning rather than a shortcut. In order to foster learning and penalize the shortcut mentality, the following should be observed: 1) Turning in the obvious output of "gcc -S" is not allowed. 2) If you choose to start with generated assembly, you should investigate the differences between "gcc -S", "gcc -S -O", and "gcc -S -O2". 3) Once you understand the differences arising from the different optimization levels, you should choose the cleanest code from among the different optimization levels and then document and alter it as needed. 4) The code you turn in should avoid unnecessary stack variables, as would be the case with no optimization. You should choose to register allocate local variables whenever possible. 5) The code you turn in should avoid redundant loads and stores, as would be the case with no optimization. The code must also eliminate repeated evaluations of common subexpressions, as would be the case with no optimization. 6) The code you turn in should have only nops in the delay slots of the control transfer instructions. 7) If you start with generated code, the code you turn in should have the local labels (.LL_) substituted with mnemonic names. 8) If you start with generated code, the code you turn in should have the non-temporary and non-parameter register names substituted with mnemonic names using the m4 define facility. There should be no code with %g_ or %l_ register names. Moreover, using %i_ or %o_ registers for non-temporary variables just to avoid mnemonic naming will be penalized in the grading. 9) Leaf optimization is allowed but discouraged. In particular, any inappropriate register usage in leaf routines will be heavily penalized in grading. I reserve the right to base your grade partially or wholly on a structured walkthrough of the assembly language version of your program. You may be required to explain the code, perhaps using unique test cases, with no materials other than the assembly language listing. If you are unable to explain your code at the assembly language level in a satisfactory manner, your grade will reflect that inability - independent of whether your program executes all test cases correctly or not.