Thursday, June 30

Finished writing the decode up! I also started debugging it for a while. I had a few hiccups but it seems to be working well now. I'll keep debugging it and then start putting it together with the existing ANDing and ORing code I have and then it should be pretty set!

Tuesday, June 28

Today I finished half of the decode up method of decoding. I finished coding the decoding of a fill word and started working on how to decode a partial fill. Tomorrow I'll finish that up which overlaps with decoding a literal so that will lead into the last part nicely. 

Monday, June 27

Heard back from David today. It looks like there was an error in the VAL paper but that my approach was correct so I'm glad I continued on a debugged the version I have. Today, I planned out the decode up algorithm by hand and I'm going to write it into my code the rest of the week. This one is much harder than the the decode down since this one takes multiple segments to make a single larger segment so there are many more different combinations of fills and literals that can result from the subsegments of the pre-decoded words.

Friday, June 24

Still haven't heard from David so I've decided to go forward with my current implementation. Today I worked on thoroughly debugging my decode down method and it seems to be working well now, after a few hurdles. I also started planning out each of the four cases of the decode up and will finish implementing it next week. 

Thursday, June 23rd

Still waiting for advice regarding the issue I posted about yesterday. There are two different ways to proceed depending on which way David says to proceed so I took the day off to make sure I'm going the right direction. If I don't have an answer by tomorrow I will proceed how I was planning on doing it and fix it later if needed. 

Wednesday, June 22

Alright, so I finished writing the decode down. I want to test it some more to make sure it works how I want it to though.

After I finished writing it, I wanted to reread through the VAL papers to make sure my code was doing exactly what the papers explain, but I think I ran into a discrepancy between them. The paper illustrates a word VAL(s=60) being decoded into a segment length of 15. The VAL(s=60) word is as follows: 1000 000000000...00000 0100 0000 0000 1110. This word represents 0100 0000 0000 1110 runs of 0s (16,398). The decoding example shows its reduction into a VAL(s=15) word of that following: 1100 011111111111111 00000000001111... which represents 16,383 runs of 0s followed by 15 runs of 0s. While this adds up to 16,398 runs of 0s like the original word before decoding, the segment length has changed from 60 to 15. This means that while the original VAL(s=60) word represents 60x16,398 0s (983,880), the VAL(s=15) segments represent 15*16,383 (245,745) and 15*15 (225) 0s. This means that if we assume the segment length has changed from 60 to 15 with the decoding process, the decoded word in the example does not represent the same number of words that the original word represents. I wrote to David to clarify the issue, so hopefully I will have an answer to this tomorrow!

Tuesday, June 21

Today I continued work on the decoding. I am almost done with writing the decoding down. When I'm done with that I will work on the more difficult decoding up. A big part of today was writing various different utilities involving the activeWord struct to hold the decoded words, including a loop that I'm rather proud of:

void updateActiveWord(activeWord *toUpdate, word_32 newWord){

     int i;

     for(i=0;i<toUpdate->numSegs;i++){

          toUpdate->flag[i]=(newWord<<(4-(toUpdate->numSegs)+i))>>((toUpdate->length*toUpdate             ->numSegs)+3);

          toUpdate->seg[i]=(newWord<<(4+(toUpdate->length*i)))>>(WORD_LENGTH-toUpdate                   ->length);

     }

     toUpdate->currSeg=0;

}

It's not actually that complicated; the main reason I'm proud of this is because all of that looped bit work worked the first time through so I did not have to debug! What a day!