DEV Community: Heavendeep Kaur Munjal

Project Stage 3

Heavendeep Kaur Munjal — Tue, 23 Apr 2024 02:35:01 +0000

Reflecting on Feedback: Enhancing the ACLE Documentation

In my journey to improve the ACLE (Architecture Compatibility Linkage Editor) documentation, I recently received valuable feedback from both my professor and a classmate, Kristjan, from my SPO600 section. Their insights shed light on important nuances and considerations that warrant attention in the ongoing development of the ACLE standard.

Classmate Feedback: Exploring Macro Behavior and Compiler Support

Kristjan's feedback focused on the behavior of certain macros and compiler support for Function Multi Versioning (FMV). He noted that while macros such as "GNUC" from the GCC documentation yielded expected results, macros specific to FMV, such as "__HAVE_FEATURE_MULTI_VERSIONING", did not provide the expected outcomes. Additionally, Kristjan encountered issues with the -fno-function-multi-versioning flag, which was not recognized by the compiler.

These observations prompt a deeper exploration into the functionality of these macros and flags across different compilers and platforms. Understanding their behavior under various conditions is crucial for ensuring the reliability and portability of code written with the ACLE standard.

Professor Feedback: Examining Current Implementation and Standards

My professor provided detailed insights into the current implementation of the ACLE standard and highlighted areas that require clarification and potential refinement. Notably, he pointed out discrepancies between the standard and the current implementation, such as unimplemented features and undefined macros.

One significant aspect highlighted by my professor is the need for alignment between the ACLE standard and compiler implementations. This ensures consistency and clarity for developers leveraging the standard across different compiler versions and architectures.

Taking Action: Engaging with the Community

In response to the feedback received, I reached out to Andrew Carlotti, a key contributor to the ACLE standard, as suggested by my professor. Engaging with Andrew allowed for a fruitful discussion on the discrepancies and potential improvements needed in the ACLE standard.

Andrew's insights provided valuable context on the current implementation challenges and outlined future directions for enhancing the standard. Collaborating with community members like Andrew is essential for driving continuous improvement and ensuring the relevance and effectiveness of the ACLE standard in real-world development scenarios.

Moving Forward: Iterative Development and Collaboration

As I continue to iterate on the ACLE documentation and contribute to the standard, I'm committed to addressing the feedback received and collaborating with the community to drive positive change. By fostering an open dialogue and actively engaging with stakeholders, we can collectively shape a robust and reliable standard that meets the evolving needs of software developers.

In conclusion, the feedback received from both my professor and classmates serves as a catalyst for further refinement and enhancement of the ACLE documentation and standard. Through ongoing collaboration and iterative development, we can empower developers with the tools and resources they need to build efficient and compatible software solutions.

The document you found provides valuable insights into the rationale and design considerations behind Function Multi Versioning (FMV) support for Arm architectures. Here's a summary and some thoughts on how you can incorporate it into your blog post:

Exploring Function Multi Versioning Support for Arm Architectures

Function Multi Versioning (FMV) is a powerful feature supported by various architectures, aimed at enhancing software development and deployment. While FMV implementation details may vary across architectures, the document sheds light on its design specifically for Arm architectures.

Rationale for FMV Support on Arm

The document emphasizes the importance of uniformity in source code formats across toolchains and platforms to simplify software development and deployment. However, due to the complexity and variability of Arm architectures, FMV support on Arm is designed to be bound to features rather than CPU implementations. This approach ensures consistency and compatibility across different Arm architectures and kernel configurations.

FMV in the Arm ACLE

Unlike some architectures where FMV might be defined in the ABI, on Arm architectures, FMV is defined in the Arm C Language Extensions (ACLE). This decision is based on the fact that FMV does not alter function behavior from the ABI perspective. Regardless of which version is called, functions derived via FMV maintain the same signature and calling convention as the original function.

To avoid confusion with existing attributes, Arm introduces target_version and target_clones attributes specifically for FMV purposes. These attributes ensure clarity and specificity when defining FMV-related behavior in the ACLE.

Feature Test Macro and Attributes

To enable users to determine the availability of FMV support in their toolchain, a feature test macro __HAVE_FUNCTION_MULTI_VERSIONING is proposed. This macro allows developers to conditionally compile code based on FMV support.

The document also outlines various use cases and considerations for FMV-aware compilers processing FMV-related attributes. Whether the compiler is aware of these attributes or not, clear guidelines ensure consistent behavior and compatibility across different compiler implementations.

Project Stage 2 : Fixing the ACLE Documentation

Heavendeep Kaur Munjal — Thu, 11 Apr 2024 00:26:16 +0000

First Step : Forking the official repo for ACLE Documentation

The first step I did was to fork the repo so that I can make the fixes to the ACLE documentation and work towards creating a Pull Request in the future.

Official Repo:

ARM-software / acle

Arm C Language Extensions (ACLE)

Arm C Language Extensions

This repository contains the source material from which the specifications for the Arm C Language Extensions (ACLE) are derived.

The latest release of the specifications can be browsed online at arm-software.github.io/acle/.

The PDF version of the documents can be retrieved from the latest release page.

The development version is stored on the branch main at github.com/ARM-software/acle/, while the latest released version is tracked by the branch latest-release.

Contributing

Contributions of any kind are always welcome! Please check the contribution guidelines for details.

Defect reports

Please report defects in or enhancements to the specifications in this folder to the issue tracker page on GitHub.

For reporting defects or enhancements to documents that currently are not yet included in this repo and are thus only hosted on developer.arm.com, please send an email to arm.acle@arm.com.

List of documents

HTML version	PDF version
Arm C

…

View on GitHub

Forked Repo:

HeavenMunjal / acle

Arm C Language Extensions (ACLE)

Arm C Language Extensions

This repository contains the source material from which the specifications for the Arm C Language Extensions (ACLE) are derived.

The latest release of the specifications can be browsed online at arm-software.github.io/acle/.

The PDF version of the documents can be retrieved from the latest release page.

The development version is stored on the branch main at github.com/ARM-software/acle/, while the latest released version is tracked by the branch latest-release.

Contributing

Contributions of any kind are always welcome! Please check the contribution guidelines for details.

Defect reports

Please report defects in or enhancements to the specifications in this folder to the issue tracker page on GitHub.

For reporting defects or enhancements to documents that currently are not yet included in this repo and are thus only hosted on developer.arm.com, please send an email to arm.acle@arm.com.

List of documents

HTML version	PDF version
Arm C

…

View on GitHub

Finding issues to work on:

After my research, looking through the issues my professor provided me, Checking the documentation myself and going through the already filed issues. i found the below:

Mentions that FMV may be disabled at compile time by a compiler flag, but this flag is not documented
The macro __HAVE_FEATURE_MULTI_VERSIONING (or __FEATURE_FUNCTION_MULTI_VERSIONING or __ARM_FEATURE_FUNCTION_MULTIVERSIONING) does not appear to be defined

1st Issue

The issue was fixed by the changes from the commit

To address the missing documentation regarding the compiler flag that disables Function Multi Versioning (FMV), we can add a section that explicitly mentions this flag and provides guidance on how to use it. Here's a proposed addition to the documentation:

Disabling Function Multi Versioning

Function Multi Versioning (FMV) can be a powerful tool for optimizing software to run on various hardware configurations. However, there may be scenarios where a developer needs to disable this feature, such as for debugging purposes or to ensure compatibility with specific hardware that does not benefit from FMV.

To disable FMV at compile time, the compiler provides a specific flag. This flag instructs the compiler not to generate multiple versions of a function based on the target attributes and to use only the default version of the function. The use of this flag ensures that the compiled binary does not contain any versioned functions other than the default.

Compiler Flag

The compiler flag to disable FMV is -fno-function-multi-versioning. This flag can be added to the compiler's command line arguments when compiling the source code.

Example usage:

gcc -fno-function-multi-versioning -o my_program my_program.c

In this example, gcc is the compiler being used to compile my_program.c. By including the -fno-function-multi-versioning flag, FMV is disabled for this compilation, ensuring that only the default versions of any multi-versioned functions are included in the final binary.

Considerations

When FMV is disabled using the -fno-function-multi-versioning flag, all __attribute__((target_version("name"))) and __attribute__((target_clones("name",...))) attributes in the source code are ignored.
Developers should carefully consider the implications of disabling FMV, as it may impact the performance optimizations that FMV can provide on supported hardware.
It is recommended to use this flag only when necessary, such as during specific testing or debugging sessions, or when targeting hardware that does not support the features used by the versioned functions.

By providing clear documentation on how to disable FMV, developers can have better control over their compilation process and make informed decisions about when and how to use FMV for their applications.

This addition clearly documents how to disable FMV, providing developers with the necessary information to control this feature during the compilation process.

2nd Issue

The second issue was fixed in the commit

To include and document the presence of a macro that indicates compiler support for Function Multi Versioning (FMV), such as __HAVE_FEATURE_MULTI_VERSIONING, __FEATURE_FUNCTION_MULTI_VERSIONING, or __ARM_FEATURE_FUNCTION_MULTIVERSIONING, you can add a section to the documentation that explains how to check for FMV support using these macros. This will guide developers on how to write conditional code that leverages FMV only when it is available.

Documenting Compiler Support for FMV

Checking for FMV Support

To write portable code that optionally uses Function Multi Versioning (FMV) features, it's crucial to check whether the compiler supports FMV. This can be done by checking predefined macros that are set by the compiler when FMV is supported. The specific macro to check can vary based on the compiler and the target architecture.

Predefined Macros for FMV Support

The compiler may define one or more of the following macros to indicate support for FMV:

__HAVE_FEATURE_MULTI_VERSIONING
__FEATURE_FUNCTION_MULTI_VERSIONING
__ARM_FEATURE_FUNCTION_MULTIVERSIONING

These macros, if defined, indicate that the compiler supports FMV and that the FMV-specific attributes (__attribute__((target_version("name"))) and __attribute__((target_clones("name",...)))) can be used in the code.

Example Usage

Before using FMV-specific attributes in your code, check if the compiler supports FMV by checking the relevant macro:

#if defined(__HAVE_FEATURE_MULTI_VERSIONING) || defined(__FEATURE_FUNCTION_MULTI_VERSIONING) || defined(__ARM_FEATURE_FUNCTION_MULTIVERSIONING)
// FMV is supported by the compiler
__attribute__((target_clones("arch1", "arch2")))
void optimized_function() {
    // Optimized implementation
}
#else
// FMV is not supported by the compiler
void optimized_function() {
    // Standard implementation
}
#endif

In this example, the optimized_function is defined with FMV-specific attributes if FMV is supported. Otherwise, a standard implementation of the function is provided.

Note to Developers

Developers should refer to their compiler's documentation to understand which macro(s) are defined when FMV is supported. This documentation may vary between compilers and target architectures. The presence of these macros allows developers to write code that is both portable and optimized for performance on supported platforms.

Conclusion

By documenting the macros that indicate FMV support, developers can conditionally compile FMV-specific code, ensuring that their applications can be compiled with or without FMV support based on the capabilities of the compiler being used. This approach enhances the portability and performance of applications across different platforms and compiler versions.

Project stage 1

Heavendeep Kaur Munjal — Wed, 10 Apr 2024 23:51:41 +0000

Procedure
First Obtain the source code for the current development version of GCC from the Git repository.
git clone

git://gcc.gnu.org/git/gcc.git

cd gcc

Task 1: Command-line Parsing

Understanding the Task
The goal is to enable AFMV directly from the GCC command line, allowing us to specify architectural feature versions for optimized code generation. This capability will be a significant step forward, particularly for applications that demand high performance on AArch64 platforms.

Navigating GCC's Codebase

Command line parsing logic lies primarily in gcc/gcc.c and gcc/common.opt files. While line numbers may shift between versions, these files serve as our entry point for integrating new AFMV options.

The Path Ahead

The task involves extending existing command line option parsing to recognize AFMV options. Careful coding ensures new options process correctly during compilation.

Tools of the Trade
We'll be using text editors or IDEs for code modifications, command-line utilities for codebase navigation, and version control systems for change management. The new options will require regular expressions and data structures.

Success Testing
The robust test cases will be constructed, and we use the GCC testing framework DejaGnu to make sure the new functionality works as supposed and maintains compatibility with current features.

Skills and Knowledge
A deep investigation into the GCC codebase, into the AArch64 architecture and into the FMV mechanism will have to be made. C programming skills and skills in debugging will also be required.

Independent Progress
To avoid getting sticky, the changes I've made to command-line parsing should remain pretty modular, with mock objects or stubs deployed at first to simulate architectural features during the initial phases.

Collaborative Integration
In further refining, the command-line parsing logic has to be easily configured for integration with the other code sections responsible for FMV cloning and pruning, so as to make the AFMV function fully functional.

Effort Estimation
The amount of effort to be applied to this task is between 40-60 hours; it depends on both the complexity of the GCC codebase and its accurate, exhaustive testing.

Conclusion
Enhancing GCC with AFMV support for the AArch64 architecture is like opening a new chapter in high-performance computing. The addition of this feature from the command line saves development time and reveals the full potential of the AArch64 architecture. Keep tuned for more updates as we continue to push the boundaries of compiler technology.

Task 2 Version List Processing

Understanding the Task
It includes extracting from the provided version list the architectural features for Gnu Compiler Collection (GCC) validation of AArch64 systems.

Navigating GCC's Codebase
Source Files: Firstly, the primary source files that handle parsing and processing command-line options in GCC reside within gcc/gcc.c and gcc/common.opt. Next, gcc/config/aarch64/aarch64.c also includes some architecture-specific code which may be relatable for validating the AArch64 features.

The Path Ahead

Enhance or tweak the command-line option parsing mechanism, including its recognition and processing of a list of architectural feature versions.
Implement validation logic to ensure that every specified feature version is one supported by the AArch64 architecture in GCC.
Integrate this validation logic smooth and seamlessly into the existing command-line processing workflow.

Tools of the Trade

Tools: Use text editors or IDEs for making code changes, grep for searching the GCC codebase, and Git for version control.
Techniques: Utilize parsing techniques for the version list and conditional logic for feature validation.

Success Testing

Design test cases for all valid and invalid version scenarios of architectural features.
Deploy the existing testing framework, which could be DejaGnu, to automatic testing and ensure compatibility with existing tests.

Skills and Knowledge

Understand, in full, the architecture of command-line processing for GCC, and AArch64 specifications in detail.
Understand the versioning for architectural features in GCC that are supported at the AArch64 level.

Independent Progress

Design the version list processing and validation as a modular component that can be built and tested independently of other enhancements.
Use mock data for architectural features during initial development to minimize dependencies on other tasks.

Collaborative Integration

Always ensure that the processed version list, which is validated, will be used correctly by the AFMV feature for generating optimized code for specified architectural features.
Adjust and coordinate with the developers working on related tasks so as to guarantee effortless integration and operation.

Effort Estimation

Estimate: Approximately 30-50 hours.
Rationale: Considering this to be the estimated hours, it includes the analysis of the relevant sections of the GCC codebase, implementation of processing and validating the version list, creation of the corresponding tests, and integrating with other AFMV-related tasks. This takes into consideration the complexity of the code of GCC and extensive testing.

Conclusion
This approach outlines a roadmap for adding version list processing capability to GCC, highlighting the steps and considerations necessary to successfully complete the task.

Task that interests me the most
Command-line parsing is very eye catching to me and sounds interesting and has such a unique task for a developer like me because it is the intersection between user experience and core functionality. It is the first point of contact between the user and the application, where commands and options are interpreted, setting the stage for how the software will function. It's a critical component that can greatly influence the usability and flexibility of a program. Command-line parsing involves a deep dive into complex problem-solving, as developers must think about a wide range of user inputs and make sure that the application behaves appropriately. The task demands precision and attention to detail; any omission can lead to big issues in how the software operates.

64-Bit Assembly Language Lab

Heavendeep Kaur Munjal — Wed, 20 Mar 2024 00:14:23 +0000

The very first thing to do is setup the the servers:

Go to the folder: cd spo600/examples/hello/assembler/
Then using make building the c files:

Open the files using cat command and By objdump -d objectfile we can look at the code:

The code to include loop index values, showing each digit from 0 to 30 in AArch64 assembly language:

.text
.global _start

start = 0                               /* loop index starting value */
max = 31                                /* loop exits when the index hits this number */

_start:
        mov     x3,start                /* set loop index */

loop:
        mov     x9,10           /* store divisor in register */
        udiv    x10,x3,x9       /* divide and store quotient in register */
        msub    x11,x9,x10,x3       /* store remainder in register */
    adr     x1,msg                  /* message location */
    cmp     x10,0           /* check if quotient is 0 */ 
    b.eq    next            /* jump if quotient is 0 */
    add     x12,x10,0x30            /* convert to ascii and store in register */
    strb    w12,[x1,6]              /* place quotient in msg */


next:
    add     x13,x11,0x30            /* convert to ascii and store in register */
    strb    w13,[x1,7]              /* place remainder in msg */
        mov     x2,len                  /* message length */
        mov     x0,1                    /* file descriptor stdout */
        mov     x8,64                   /* syscall sys_write */
        svc     0                       /* syscall */

        add     x3,x3,1                 /* increment index */
        cmp     x3,max                  /* check if index is at max */
        b.ne    loop                    /* loop if index not at max */

        mov     x0,0                    /* exit status */
        mov     x8,93                   /* syscall sys_exit */
        svc     0                       /* syscall */

.data

msg:    .ascii  "Loop:   \n"
.set len, . - msg

In x86_64 assembly language program:

.text
.global  _start

start = 0               /* loop index starting value */
max = 31                /* loop exits when the index hits this number */

_start:
    mov     $start,%r15     /* set loop index */

loop:
    mov $0,%rdx         /* clear register */
    mov %r15,%rax       /* store dividend in register */
    mov $10,%r10        /* store divisor in register */
    div %r10            /* divide */
    mov %rax,%r11       /* store quotient in register */
    mov %rdx,%r12       /* store remainder in register */
    cmp $0,%r11         /* check if quotient is 0 */
    je  next            /* jump if quotient is 0 */
    add $0x30,%r11      /* convert to ascii */
    mov %r11b,msg+6     /* place quotient in msg */

next:
    add $0x30,%r12      /* convert to ascii */
    mov %r12b,msg+7     /* place remainder in msg */
        mov $len,%rdx       /* message length */
        mov $msg,%rsi       /* message location */
        mov $1,%rdi         /* file descriptor stdout */
        mov $1,%rax         /* syscall sys_write */
        syscall             /* syscall */

    inc     %r15            /* increment index */
    cmp     $max,%r15       /* check if index is at max */
    jne     loop            /* loop if index not at max */

        mov $0,%rdi         /* exit status */
        mov $60,%rax        /* syscall sys_exit */
        syscall             /* syscall */

.data

msg:    .ascii      "Loop:   \n"
.set len , . - msg

In conclusion, exploring assembly programming across diverse architectures provided invaluable insights into low-level computing. From the nostalgic simplicity of 6502 to the complex optimizations of x86_64 and AArch64, each architecture challenged and expanded my understanding, enriching my programming journey with hands-on experience and newfound

Assembly language code

Heavendeep Kaur Munjal — Mon, 05 Feb 2024 16:32:09 +0000

About:
maze game using zero-page variables for efficient memory access and execution speed. These variables include ROW, COL, DRAWN_ROW, MAZE_L, MAZE_H, PLAYER_L, PLAYER_H, TARGET_L, and TARGET_H. ROW and COL track the player's current position in the maze, while DRAWN_ROW counts the drawn rows on the screen. MAZE_L and MAZE_H point to where the maze is drawn, and PLAYER_L and PLAYER_H point to the player's position. TARGET_L and TARGET_H point to the target position the player aims to reach. Zero-page variables optimize memory usage and speed up access to critical data during execution, crucial for game performance. The code initializes the game, manages player movements, checks for collisions, and handles game completion. It uses ROM routines for screen initialization and displays instructions and completion messages. Maze data, help text, and completion messages are provided in the code. The game loop continuously updates the player's position, receives user input, checks for collisions, and displays appropriate messages upon game completion. By leveraging zero-page variables, the code enhances memory management and execution efficiency, essential for smooth gameplay in assembly-based maze games.

Code:
; zero-page variables
define NEW_ROW $20 ; current row
define NEW_COL $21 ; current column
define NEW_DRAWN_ROW $22 ; number of drawn rows
define NEW_MAZE_L $14 ; a pointer that points to where the maze will
define NEW_MAZE_H $15 ; be drawn
define NEW_PLAYER_L $10 ; a pointer that points to the player in the
; screen
define NEW_PLAYER_H $11
define NEW_TARGET_L $12 ; a pointer that points to the target position
define NEW_TARGET_H $13 ; where the player wants to proceed

; constants
define PATH $03 ; path color
define PLAYER $0e ; player color
define HEIGHT 7 ; height of the maze
define WIDTH 7 ; width of the maze

; ROM routine
define SCINIT $ff81 ; initialize/clear screen

    jsr printHelp
    jsr drawMaze
    jsr gameInit
    jsr gameLoop

printHelp: ldy #$00 ; print instructions on the screen
pHelpLoop: lda help,y
beq done
sta $f000,y
iny
bne pHelpLoop

gameInit: lda #$01 ; initialize ROW, COL to make the player
sta NEW_ROW ; starting at $0221 of the screen
sta NEW_COL
rts

gameLoop: jsr updatePosition
jsr getkey
jsr checkCollision
ldx #$00 ; clear out the key buffer
stx $ff
jmp gameLoop

updatePosition: ldy NEW_ROW ; load PLAYER pointer with ROW
lda table_low,y
sta NEW_PLAYER_L
lda table_high,y
sta NEW_PLAYER_H

    ldy NEW_COL     ; place the player at (POINTER + COL)
    lda #PLAYER
    sta (NEW_PLAYER_L),y
    rts

getkey: lda $ff ; get the input key

    cmp #$80    ; allow arrow keys only
    bmi getkey
    cmp #$84
    bpl getkey

    pha     ; save the accumulator
    lda #PATH   ; set color of the current position to PATH
    sta (NEW_PLAYER_L),y
    pla     ; restore accumulator

    cmp #$80    ; check key is up
    bne checkRight

    dec NEW_ROW     ; ... if yes, decrement ROW
    rts

checkRight: cmp #$81 ; check if key is right
bne checkDown
inc NEW_COL ; ... if yes, increment COL
rts

checkDown: cmp #$82 ; check if key is down
bne checkLeft
inc NEW_ROW ; ... if yes, increment ROW
rts

checkLeft: cmp #$83 ; check if key is left
bne done
dec NEW_COL ; ... if yes, decrement COL
rts

done: rts ; break out of a loop or subroutine

checkCollision: ldy NEW_ROW ; load TARGET pointer with ROW
lda table_low,y
sta NEW_TARGET_L
lda table_high,y
sta NEW_TARGET_H

    ldy NEW_COL     ; load the color from the target
    lda (NEW_TARGET_L),y; at (POINTER + COL)

    cmp #$01
    beq done
    cmp #$03
    beq done
    cmp #$0a
    beq gameComplete

    lda #$00
    sta (NEW_TARGET_L),y

    lda $ff
    cmp #$80    ; if input key was up...
    bne ifRight

    inc NEW_ROW     ; ... if yes, increment ROW
    rts

ifRight: cmp #$81 ; if input key was right...
bne ifDown

    dec NEW_COL     ; ... if yes, decrement COL
    rts

ifDown: cmp #$82 ; if input key was down...
bne ifLeft

    dec NEW_ROW     ; ... if yes, decrement ROW
    rts

ifLeft: cmp #$83 ; if input key was left...
bne done

    inc NEW_COL     ; ... if yes, increment COL
    rts

gameComplete: jsr SCINIT
ldy #$00 ; print game completion message on the screen
pGameComplete: lda complete,y
beq done
sta $f000,y
iny
bne pGameComplete
brk

drawMaze: lda #$21 ; a pointer pointing to the first pixel
sta NEW_MAZE_L ; of the screen
lda #$02
sta NEW_MAZE_H

    lda #$00    ; number of drawn rows
    sta NEW_DRAWN_ROW

    ldx #$00    ; maze data index
    ldy #$00    ; column index

draw: lda maze_data,x
sta (NEW_MAZE_L), y
inx
iny
cpy #WIDTH ; compare with the number of WIDTH
bne draw ; if not, keep drawing the column

    inc NEW_DRAWN_ROW   ; increment the number of row
    lda #HEIGHT
    cmp NEW_DRAWN_ROW   ; compare with the number of HEIGHT
    beq done

    lda NEW_MAZE_L
    clc
    adc #$20    ; add 32(0x0020) to increment the row
    sta NEW_MAZE_L  ; of the pixel
    lda NEW_MAZE_H
    adc #$00
    sta NEW_MAZE_H

    ldy #$00    ; reset the column index for the new row
    beq draw

; help text message
help:
dcb "P","l","a","y",32,"w","i","t","h",32,"a","r","r","o","w"
dcb 32,"k","e","y","s",32,"t","o",32,"c","o","n","t","r","o","l",10
dcb 00

; game complete message
complete:
dcb "Y","o","u",32,"c","o","m", "p", "l", "e", "t", "e", "d", 32
dcb "t","h","e",32,"g","a","m","e","!"
dcb 00

; maze map data
maze_data:
dcb 01,00,01,00,01,01,01
dcb 01,01,01,00,00,00,01
dcb 00,00,01,00,01,00,01
dcb 01,00,01,00,01,01,01
dcb 01,00,01,00,01,00,01
dcb 01,00,01,00,01,00,01
dcb 01,01,01,01,01,00,10

; these two tables contain the high and low bytes
; of the addresses of the start of each row
table_high:
dcb $02,$02,$02,$02,$02,$02,$02,$02
dcb $03,$03,$03,$03,$03,$03,$03,$03
dcb $04,$04,$04,$04,$04,$04,$04,$04
dcb $05,$05,$05,$05,$05,$05,$05,$05

table_low:
dcb $00,$20,$40,$60,$80,$a0,$c0,$e0
dcb $00,$20,$40,$60,$80,$a0,$c0,$e0
dcb $00,$20,$40,$60,$80,$a0,$c0,$e0
dcb $00,$20,$40,$60,$80,$a0,$c0,$e0

User input: keyboard keys

Moving:

Finished: the red mark changes to green

Output:

Summary:
It was a very fun lab. I have made maze before but with python and using assembly language was a game changer for me. This could be made with more difficult mazes and level up with time.

Introduction to 6502 Assembly Language

Heavendeep Kaur Munjal — Wed, 31 Jan 2024 19:46:01 +0000

Welcome to the kickoff of our journey into the captivating world of assembly language programming! In this hands-on lab, dive into the basics of 6502 assembly language using the 6502 Emulator. Through experimentation and optimization, uncovered valuable insights that set the stage for mastering more complex assembly languages such as x86_64 and AArch64. Let's dive in and have fun!

Setting Up
Began the lab by opening the 6502 Emulator in a new tab or window. Kept this guide handy for reference as you navigate through the lab.
Note: Remember to save the work periodically using git or by copying the code to local files, as the emulator does not automatically save your progress.

Bitmap Code
Added the code provided in the lab into the emulator and then assembled and then ran on the site.

The code provided gives the color yellow.

Calculating Performance:

Decrease the time taken to fill the screen with a solid colour:
To reduce the time needed to fill the screen with a solid color, we can optimize the loop structure and improve memory access efficiency.

lda #$00 ; set a pointer in memory location $40 to point $0200

sta $40 ; ... low byte ($00) goes in address $40
lda #$02
sta $41 ; ... high byte ($02) goes into address $41
lda #$07 ; colour number

ldx #$00 ; set X register to 0
lda #$07 ; load accumulator with color number

fill_loop:
sta ($40),x ; set pixel color at the address (pointer)+X
inx ; increment index
bne fill_loop ; continue until X reaches 0 again
inc $41 ; increment the page
cpx #$06 ; compare with 6
bne fill_loop ; continue until done all pages

it utilize the X register to iterate through the 256 pixels of a page, eliminating the necessity for the Y register and its associated instructions.
By removing the Y register and its increment instruction, we save cycles.
Reducing the number of branching instructions is achieved by employing the X register to loop through the pixels.
The need to load Y with #$00 and increment it inside the loop has been eliminated.

Total cycles:
5+(256×(5+2))+5+3×6=5+(256×7)+5+18=5+1797+5+18=1825 cycles

Code now showing light blue instead of yellow
modified the code by: lda #$e ; colour number

Code now changing display with a different color on each page

      lda #$00    ; set a pointer at $40 to point to $0200
    sta $40
    lda #$02
    sta $41

    lda #$06    ; colour number
    sta $10 ; store colour number to memory location $10

    ldy #$00    ; set index to 0

loop: sta ($40),y ; set pixel at the address (pointer)+Y

    iny ; increment index
    bne loop    ; continue until done the page

    inc $41 ; increment the page

    inc $10 ; increment the color number
    lda $10 ; colour number

    ldx $41 ; get the current page number
    cpx #$06 ; compare with 6
    bne loop ; continue until done all pages

Reflection:

Lab 1 in assembly language programming (ALP) and the 6502 Emulator environment was an enlightening experience for a newcomer like myself. Setting up the emulator was straightforward, emphasizing the importance of file management and version control using tools like git. Exploring the provided bitmap code was both fascinating and challenging, requiring a deep understanding of each instruction's purpose and sequence. Calculating the code's performance metrics, including execution time and memory usage, was a new concept that demanded attention to detail and system constraints. Optimizing the code to decrease execution time underscored the significance of algorithmic efficiency and resource utilization in ALP. Modifying the code to experiment with different colors on the display expanded my understanding of memory manipulation and graphical output. Despite the challenges, Lab 1 sparked a sense of curiosity and eagerness to delve deeper into ALP and low-level programming. The hands-on nature of the lab provided valuable insights into system architecture and optimization techniques, laying a strong foundation for future exploration and learning in the realm of assembly language programming.