CSE 30 -- Assignment 6 -- Nov 30


Grade distrbution:

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.024701
new! driver.asm. Run this with your bitblt implementation by:
% cat driver.asm bitblt.asm > all.asm
% spim -file all.asm < test_data.txt | more
To 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 0028257e
When 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.

new! 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.

new! 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 | more
and page through the results.

Not sure how to pass more than 4 arguments? Look here.

spim and xspim allow constants in the form

WIDTH=800
but 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

You are the project leader and renowned assembly language hacker in the Electronic Book project. To keep parts count low, the eBook does not have a hardware bit-blitter. The rendering is done to off-screen memory (while the user is reading the current page), and the bitblt routine is used to scroll the screen or update to the next page. If bitblt is used to scroll or move windows around, then the source and destination graphics memory buffer is identical, and only the source and destination rectangles are different. If bitblt is used to "flip" to the next page, however, the source and destination graphics memory regions will be different. (bitblt is used to copy the current page to the previous-page graphics memory buffer, and then copy the next-page buffer to the visible buffer. the eBook renderer is then invoked to draw the next page in the next-page buffer while the user is reading the current page.)

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.


[ search CSE | CSE home | bsy's home page | webster i/f | yahoo | hotbot | lycos | altavista | pgp key svr | spam | commerce ]
picture of bsy

bsy+cse30.f99@cs.ucsd.edu, last updated Mon Dec 20 20:26:14 PST 1999. Copyright 1999 Bennet Yee.
email bsy.


Don't make me hand over my privacy keys!