PART A: Mathematical Functions

In this section, I focused on implementing fundamental matrix operations commonly used in neural networks. Specifically, I developed functions for dot product, matrix multiplication, element-wise ReLU, and ArgMax.

All matrices were represented as 1D vectors in row-major order. This representation required careful attention to memory access patterns, particularly when working with strides to access elements non-contiguously in memory.

---

Challenges and Solutions

1. Input Handling: Flattening the 2D Matrix

Challenge:
Transforming a 2D matrix into a 1D vector was the first hurdle. Working with MNIST-like data, I had to ensure that the flattened representation accurately followed the row-major order.

Solution:
Through precise index calculations, I ensured that each row of the 2D matrix was concatenated correctly. This set a solid foundation for subsequent matrix operations.

---

2. ReLU Implementation

Implementation:
ReLU was implemented by looping through the input array, using the index i as a pointer to process each value individually. Negative values were replaced with zero.

Challenge:
The VENUS system call requires a0 as the control register. During static data testing, using a0 for output caused conflicts when performing system calls.

Solution:
To resolve this, I temporarily stored output in a1 before making system calls, ensuring that a0 could properly control the output.

---

3. ArgMax Implementation

Implementation:
ArgMax was based on a "max register" function. The algorithm iterated through the array, comparing each element and updating the "reg_kingdom" (max value register) when a new maximum was found. Simultaneously, it tracked the corresponding index of the maximum value.

---

4. Dot Product Implementation

Thought Process:

• Version 1:
  The initial implementation focused on functionality, assuming both arrays had the same stride. Sizes size1 and size2 were independently configurable.

  ⚠️ Key Issues:

  • The dot product’s role in matmul assumes stride1 = 1 and stride2 = matrixB_col.
  • The sizes of both arrays must match by design.

• Version 2 (Improvements):
  Added the ability to handle different strides (stride1 and stride2).

  🔑 Key Insights:

  • For matmul, stride1 is always 1, while stride2 typically exceeds 1 (e.g., the number of columns in matrix B).

  Additionally, I reduced the number of registers by combining size1 and size2 into a single size register.

Future Improvements:
Develop a version where both stride1 and stride2 can be independently configurable, enhancing the function's general utility.

---

5. Matrix Multiplication (MatMul) Implementation

Implementation:
Matrix multiplication was achieved by calculating the dot product between rows of M1 and columns of M2. This process repeated for each pair, with the total number of computations equaling M1_col_number × M2_row_number.

---

Key Takeaways from PART A

1. Static Memory Allocation for Testing

Throughout PART A, I learned to define static memory in the data segment for testing each function. This approach allowed for easy verification of function outputs without worrying about dynamic memory issues during initial development.

---

2. Debugging with VENUS Web Simulator

Debugging assembly can be daunting, but VENUS Web Simulator proved invaluable. By stepping through each instruction and observing register values, I could pinpoint errors. Setting breakpoints using EBREAK allowed me to halt execution at critical points, making the debugging process more manageable and systematic.

---

3. Mastery of Function Calling Conventions

Implementing these functions solidified my understanding of RISC-V calling conventions. Specifically:

• Caller-saved registers (reg_a, reg_t) were used for temporary values.
• Callee-saved registers (reg_s, reg_ra) ensured that critical values were preserved across function calls.

Through practice, I became adept at crafting robust prologue and epilogue sections for each function, ensuring that register states were properly saved and restored.

---

Final Reflection on PART A

This section was a deep dive into low-level programming and assembly concepts. It challenged my understanding of memory management, register handling, and function calling conventions. By the end, I felt more confident in writing efficient, bug-free assembly code, a foundational skill for building more complex systems in the future.