50 students handed in assignment 6. assignment 6 as a whole: mean 54.62 stdev 23.2997 w/o late adjustment: mean 55 stdev 23.8747 Excluding all-zero scores: assignment 6 as a whole: mean 55.7347 stdev 22.1772 w/o late adjustment: mean 56.1224 stdev 22.7736 Per-problem statistics: Num 1: mean 28.600000 stdev 16.853486 Num 2: mean 26.400000 stdev 9.697422 Per-problem statistics, omitting zero grades: Num 1: mean 29.791667 stdev 16.136086 Num 2: mean 26.938776 stdev 9.024701driver.asm. Run this with your bitblt implementation by:
% cat driver.asm bitblt.asm > all.asm % spim -file all.asm < test_data.txt | moreTo try it out, use an empty bitblt in bitblt.asm, e.g.,
% cat bitblt.asm bitblt: jr $ra
I've written my translation of the slow C code. It gives identical output as hilevel.c. The instruction count from spim when it's run on the test_data.txt as above is:
Total instructions since program load = 0x00000000 0028257eWhen we test your code, we will use several test cases, including overlapping bitblt for all the alignment cases. Beware of the cases where the width is less than 32.
You should turn in your bitblt.asm file, a consts.asm file if you need to use any constants that depend on WIDTH and HEIGHT that aren't available from driver.asm -- be sure to document how to set these, since we may want to test your bitblt code with different size displays for use in future eBook models.
Turn in any test cases you used to debug your code as well. You should comment your code. If you wrote a C version as an initial design step that led to the the assembly, include that as part of the documentation.
C impl updated. A single set of test data is now available. To try it out, put the C code in a file named hilevel.c, compile it and run the executable with the test data, in file test_data.txt as input:
% cc -o hilevel hilevel.c % ./hilevel < test_data.txt | moreand page through the results.
Not sure how to pass more than 4 arguments? Look here.
spim and xspim allow constants in the form
WIDTH=800but they do not evaluate expressions, so you can't do
WORDS_PER_ROW=((WIDTH+BITS_PER_WORD-1)/BITS_PER_WORD)instead, calculate the number yourself, e.g,
WORDS_PER_ROW=25
Unfortunately, preliminary studies show that the C implementation of bitblt isn't fast enough. Your job, as the project lead / chief assembly language hacker, is to make it as fast as possible. The eBook is your company's first product, and the bitblt code should be sped up by a factor of at least 30-40 to be acceptable for consumers. The manufacturing line is awaiting your speed improvements, and these must be done by midnight Sunday, December 12th (due date) in order for your eBook product to be available to consumers for the Christmas shopping season. (This is wildly optimistic, by the way.)
Your President and CEO is offering you big piles of stock options, since this is a make-or-break product for your company. The IPO value greatly depends on how well this product is accepted, and interactive performance is critical. The IPO will occur early next year.
See the possibly buggy C code that your programmers had written. This can be a starting point for your super-efficient code.
You should be able to achieve a factor of 30-40 speed improvement.
bsy+cse30.f99@cs.ucsd.edu, last updated
email bsy.