Approach for Version List Processing

This is the step by step approach, I will be following to implement the Version List Processing task:

1. Understand the Requirements: Make sure to fully understand what the version list processing task entails. Review the project goal and the specific requirements outlined for this task.

2. Identify Dependencies: Determine if there are any dependencies or prerequisites for this task. For example, does it require knowledge of other parts of the codebase, or does it depend on completion of other tasks?

3. Set Up My Development Environment: Ensure I have the necessary tools and resources to work on the task. This might include setting up a development environment with GCC and any other required software.

4. Familiarize Myself with the Codebase: Spend some time familiarizing myself with the relevant parts of the GCC codebase. Understand where the version list processing code will fit in and how it will interact with other components.

5. Implement Command-line Parsing: Start by implementing the command-line parsing functionality if it's not already in place from Cameron, or might get some guidance from him in what I might expect from him to make an example in place. This will involve parsing the compiler command-line arguments to pick up AFMV options and storing them in appropriate data structures.

6. Stub Out Version List Processing: Create stub functions or placeholders for the version list processing logic. These can be basic functions that accept hard-coded input values or read values from a file for testing purposes.

7. Test My Implementation: Test the command-line parsing functionality and the stubbed-out version list processing logic to ensure they're working correctly. This might involve writing test cases to verify that the expected input values are being parsed and processed correctly.

8. Iterate and Refine: Iterate on my implementation, refining and improving it as needed. As I gain a better understanding of the codebase and the requirements of the task, I may need to make adjustments to my implementation.

9. Connect with Other Tasks: Once I have a basic version of the version list processing functionality in place, I can start connecting it with other tasks as needed. This might involve integrating it with the FMV Cloning functionality or other parts of the compiler codebase.

10. Document My Work: Document My implementation, including any design decisions, assumptions, and testing procedures. This documentation will be valuable for my own reference and for others who may need to work with or review my code.

Project Stage 1: Version List Processing and Update Documentation

Version List Processing

Lead: Muhammad Wajih Rajani

Description:

- The task involves processing the version list received from the command-line to validate the architectural features.

- This includes parsing the list of architectural feature versions provided as command-line options.

- The parsed features need to be validated against the existing FMV code to ensure compatibility and correctness.

Approach:

1. Parsing Command-line Options: Use command-line parsing libraries or write custom code to extract the AFMV options provided by the user.

2. Validation of Architectural Features: Compare the parsed features against the existing FMV codebase to ensure compatibility and correctness.

3. Error Handling: Implement appropriate error handling mechanisms to deal with invalid or unsupported architectural feature versions.

Testing:

- Test the version list processing functionality with various combinations of AFMV options.

- Verify that valid options are accepted, and invalid options are rejected with informative error messages.

Skills and Knowledge Required:

- Proficiency in C/C++ programming language.

- Understanding of GCC codebase structure and organization.

- Familiarity with command-line parsing techniques and error handling in C/C++.

Independence from Other Tasks:

- Version list processing can be developed independently of other tasks as it primarily involves working with command-line arguments and validating feature versions.

- It does not depend on the completion of other tasks such as automatic cloning or diagnostic output.

Interface with Other Tasks:

- The version list processing functionality will interface with the command-line parsing module developed by Cameron Coenjarts to retrieve AFMV options.

- It may also interact with the automatic cloning task to ensure that the validated architectural features are correctly applied during function cloning.

Estimated Work Hours:

- Parsing Command-line Options: 4 hours

- Validation of Architectural Features: 6 hours

- Error Handling: 2 hours

- Total: 12 hours

Update Documentation

Description:

- The task involves updating the existing GCC IFUNC and FMV documentation for all architectures.

- Additionally, it requires creating documentation specifically for the AFMV feature introduced in this project.

Approach:

1. Review Existing Documentation: Familiarize yourself with the current IFUNC and FMV documentation available in the GCC codebase.

2. Identify Changes: Identify sections of the documentation that need to be updated to reflect the changes introduced by the AFMV feature.

3. Create New Documentation: Develop new documentation specifically detailing the AFMV feature, including usage instructions and examples.

Testing:

- Review the updated and new documentation to ensure clarity, correctness, and completeness.

- Seek feedback from team members and potential users to refine the documentation further.

Skills and Knowledge Required:

- Proficiency in technical writing and documentation.

- Understanding of GCC architecture and feature sets.

- Ability to translate technical concepts into clear and concise documentation for users.

Independence from Other Tasks:

- Documentation can be updated and created independently of other tasks, as it primarily involves writing and editing text.

- It does not require changes to the codebase or interaction with other modules.

Interface with Other Tasks:

- The updated documentation will serve as a reference for users and developers implementing AFMV and related features.

- Feedback from other task leads and developers may inform updates and improvements to the documentation.

Estimated Work Hours:

- Review Existing Documentation: 2 hours

- Identify Changes: 2 hours

- Create New Documentation: 8 hours

- Total: 12 hours

Preference Task:

My preference from the tasks above would be version list processing, as it is more integral to the course and crucial for the completion of the project. I hope to achieve a higher score by focusing on this task.

I am very confident that I will be able to complete my work successfully. It is of significant interest to me, and completing it will improve my chances of receiving a better grade for university applications.

Writing Assembly Code: AArch64 vs x86_64

Writing assembly code can be an enlightening experience, offering a deep dive into the inner workings of a computer's architecture. In this blog post on Lab 3, we'll explore the process of writing and debugging assembly code for two different architectures: AArch64 and x86_64. We'll contrast the two and share our experiences with each.

AArch64 Assembly Code

Here's a snippet of assembly code written for the AArch64 architecture:

.text

.globl _start

min_val = 0

max_val = 30

zero_char = 0x30

_start:

    mov     x19, min_val

    mov     w6, zero_char

    mov     w7, zero_char

loop:

    mov     x0, 1

    adr     x1, msg

    mov     x2, len

    mov     x8, 64

    mov     x23, 0xA

    udiv    x24, x19, x23

    msub    x25, x24, x23, x19

    cmp     x24, 0x0

    b.eq    setup_second_digit

    mov     w6, w24

    mov     w7, w25

    mov     w26, zero_char

    add     w6, w6, w26

    add     w7, w7, w26

    add     x3, x1, 6

    strb    w6, [x3]

setup_second_digit:

    add     x3, x1, 7

    strb    w7, [x3]

    svc     0

    add     x19, x19, 1

    add     w7, w7, 1

    cmp     x19, max_val

    b.ne    loop

    mov     x0, 0

    mov     x8, 93

    svc     0

.data

msg:            .ascii      "Loop:   \n"

len=    . - msg

Explanation:

- The code begins with `.text` directive, indicating the start of executable instructions.

- `_start` is declared as the entry point of the program.

- Constants such as `loop_index`, `loop_max`, and `zero_char` are defined.

- The loop iterates from `loop_index` to `loop_max`.

- Inside the loop, the current index is divided to obtain the first and second digits.

- ASCII characters for the digits are obtained and stored in the `msg` string.

- The message is printed to the standard output using the `syscall` instruction.

- The loop continues until `loop_index` reaches `loop_max`.

- Finally, the program exits with a system call.

- This is what the loop prints on screen:

[mwrajani@aarch64-001 lab3]$ ./loop

Loop:  0

Loop:  1

Loop:  2

Loop:  3

Loop:  4

Loop:  5

Loop:  6

Loop:  7

Loop:  8

Loop:  9

Loop: 10

Loop: 11

Loop: 12

Loop: 13

Loop: 14

Loop: 15

Loop: 16

Loop: 17

Loop: 18

Loop: 19

Loop: 20

Loop: 21

Loop: 22

Loop: 23

Loop: 24

Loop: 25

Loop: 26

Loop: 27

Loop: 28

Loop: 29

x86_64 Assembly Code

Here's a snippet of assembly code written for the x86_64 architecture:

.text

.globl _start

loop_index = 0

loop_max = 30

zero_char = 48

_start:

    movq    $loop_index, %rbx

loop:

    movq    %rbx,  %rax

    movq    $10,   %rcx

    xor     %rdx, %rdx

    div     %rcx

    add     $zero_char, %rdx

    cmp     $0, %rax

    je      setup_second_digit

    add     $zero_char, %rax

    movq    $msg, %rdi

    add     $6,   %rdi

    stosb

setup_second_digit:

    movq    $msg, %rdi

    add     $7,   %rdi

    movq    %rdx, %rax

    stosb

    movq    $1,   %rdi

    movq    $msg, %rsi

    movq    $len, %rdx

    movq    $1,   %rax

    syscall

    inc     %rbx

    cmp     $loop_max, %rbx

    jne     loop

    mov     $0,  %rdi

    mov     $60, %rax

    syscall

.data

msg:            .ascii      "Loop:   \n"

len=    . - msg

Explanation:

- The code starts with `.text` directive and `_start` as the entry point.

- Constants such as `min_val`, `max_val`, and `zero_char` are defined.

- The loop iterates from `min_val` to `max_val`.

- Inside the loop, the current index is divided to obtain the first and second digits.

- ASCII characters for the digits are obtained and stored in the `msg` string.

- The message is printed to the standard output using the `svc` instruction.

- The loop continues until `min_val` reaches `max_val`.

- Finally, the program exits with a system call.

- This is what the loop prints on screen, although it is the same as aarch64, but it is expected as we are also doing the same thing:

[mwrajani@x86-001 lab3]$ ./loop

Loop:  0

Loop:  1

Loop:  2

Loop:  3

Loop:  4

Loop:  5

Loop:  6

Loop:  7

Loop:  8

Loop:  9

Loop: 10

Loop: 11

Loop: 12

Loop: 13

Loop: 14

Loop: 15

Loop: 16

Loop: 17

Loop: 18

Loop: 19

Loop: 20

Loop: 21

Loop: 22

Loop: 23

Loop: 24

Loop: 25

Loop: 26

Loop: 27

Loop: 28

Loop: 29

Writing and Debugging Experience

Writing assembly code for both architectures offers a unique insight into how the underlying hardware operates. AArch64 assembly, with its distinct syntax and register names, requires a thorough understanding of the architecture's instruction set. Debugging AArch64 code often involves meticulous examination of register values and memory accesses.

On the other hand, x86_64 assembly, being more ubiquitous, may feel more familiar to those accustomed to Intel-based systems. Debugging x86_64 code is aided by the availability of numerous tools and resources, making it relatively straightforward to identify and fix issues.

Conclusion

In conclusion, writing assembly code for AArch64 and x86_64 architectures provides valuable insights into low-level system operations. While each architecture has its own syntax and nuances, the fundamentals of assembly programming remain consistent. By understanding these differences, developers can gain a deeper appreciation for the inner workings of modern computing systems.