Lab 3 Progress

-
Over the last two weeks, I have been collaborating with my peers for lab 3. I have chosen the two-digit decimal display as my lab, I believe this task to be just enough of a challenge to push my understanding of the assembly language.

So far, I have familiarized myself with the DCB opcode, as well as reading from a set of DCB and printing to the screen. Currently my lab 3 prototype declares a zero and a one, and can display either. I have also began to work with keyboard input, reading a keypress, comparing against a hex value, and executing an instruction based on that keypress. I believe that these two things are the backbone of this task for lab 3.

The final unknown for lab 3 is a bug that occurs in my current code. When I draw my initial value (00) on the bitmap, the second 0 (the rightmost digit) prints a 1 directly below it. I believe this happens because my iterator for the amount of rows printed for the second digit does not know when to terminate, and continues printing even after it goes out of the boundary of the 0 DCB. Since I declare my 0 and my 1 contiguously in memory, the 1 is then printed underneath the 0. This could be utilized in the final application to increment or decrement the digit using pointer arithmetic, I could add a value to the pointer of my 0 DCB that is the size in memory of one digit (8x8 DCB) and print that value. If this works, this will allow me to access my 1 DCB (or any DCB, as long as they are contiguous) from my reference of the 0 DCB.

My main issue with assembly language at this time is how it structurally differs from most high level programming languages. I have been relying on function calls in my code for so long that the BNE, JMP, BCC, and other 'goto-esque' opcodes occasionally confuse me. I am getting used to them, however.

Take a look at my lab 3 WIP here

Comments

Post a Comment

Popular posts from this blog

Project Part 3

-
Image
Alright, let's start off with the most relevant function: mainSimpleSort (50%, 28%) Right off the bat, there's a tiny bit of hoisting that was half-done but seems to have been forgotten. As you can see, lo + h - 1  is loop invariant. lo + h   is actually calculated outside the loop at the very beginning of the function, but   it is used as a counter. I will create a separate variable called loHi_1  and hoist this calculation. This hoist can be repeated three times, since there are three separate instances of this condition in three separate loops. Another hoist we can do is move the v+d  calculation outside the loop. I've repeated the same procedure, storing this result into a variable called  v_d . At this point in my blog post, I would like to thank the person who created the bZip2 makefile. At the end of the makefile, there are six small sample files that are run through the bZip2 function suite (decompress, compress, recompress) and their results are automatically
Read more

Lab 5 x86_64 Update

-
This post will serve as a follow up post to the previous. The second part of lab 5 was fairly straightforward, and therefore this post will be fairly short since most of the content was covered in the previous post. The logic between the AArch64 version and x86_64 version has barely changed, the main notable difference is the use of the rax and rdx registers as the division quotient and remainder. This also removes the msub logic required on the AArch64 version, meaning that the code is very slightly smaller. Finally, instead of using the 48 decimal value to convert to ascii, I opted to use the hexadecimal 0x30. This produces the same result, but I decided on hex just to prove that I can do it. You can take a look at the x86_64 version  here .
Read more
-
Hello all. I'm Ben. This is my blog for SPO600, where I will be posting content relevant to the course. I have experience with many high level programming languages (ex. C, C++, Java, Perl, Python) and web languages (ex. NodeJS, PHP, learning asp.NET), but I have never worked with a low level language such as Assembly. The main reason I enrolled in SPO600 this semester was because of the 'optimization' portion of the course. I know I am capable of programming, but I am not sure if I am programming well. I hope to learn how to program well, to use less CPU cycles, less memory, re-use variables, and improve the quality of my code. I look forward to the rest of the semester in SPO600.
Read more