DEV Community: Joyce Wei

SPO600 - Inline Assembler

Joyce Wei — Thu, 16 Dec 2021 04:55:25 +0000

Inline Assembly is the assembly language code which is being embedded into the program written in another programming language. The most commonly programming language is C.

To embedded assembly language code into a C program, we can use one of the following forms: asm(...); or __asm__ (...);.

We can use asm("..." "..."); noticed there is a space between or asm("...\n ...") to indicate the line break of the assembly code, and use 'asm("\t")' to indicate a tab.

Input and Output Operands

= - output-only register: discarded the previous content and replaced with output value

int x=10, y;
__asm__ ("mov %1,%0"  // "mov [destination], [source]"

   : "=r"(y)    // output register value is moved to y
                // register is called %0 in template

   : "r"(x)     // input value from x is placed in a register
                // register is called %1 in template
   :
);

+ - input and output register: the register can input the value to the assembly code and output the value from the assembly code.

int x=10, y;
__asm__ ("mov %1,%0"
   : "+r"(y)       // + indicates read/write register
   : "0"(x)        // output register is same as %0
   :
);

SPO600 - Profiling

Joyce Wei — Thu, 16 Dec 2021 04:36:59 +0000

Profiling is the process of analyzing software performance based on the time, memory, temporary storage and energy where the time includes total real time, user time and the time that kernel spent.

There are two techniques to determine the resource usage on a per-function basis. The first technique is sampling which keeps interrupting the program and determining which function is currently executing. The second technique is instrumentation which sets a breakpoint to where we are interested in and determine when and how often the code is take place.

SPO600 Project Stage 3

Joyce Wei — Thu, 16 Dec 2021 03:21:30 +0000

Introduction

The stage three of SPO600 project is required to recommend how the open source package VLC from stage two should be extended to support SVE2. The difference between SVE and SVE2 is that the SVE is fixed-width, whereas SVE2 is variable-width and has additional functional coverage of instruction set that SVE has.

SVE2 Enhancements

The ARMv9 architecture released this year supports SVE2 which is a superset of SVE and Neon. According to the official document, the SVE2 instruction set can accelerate the common algorithms for multimedia application which is VLC needed. From the file merge_sve.S and merge_arm64.S we can see the software is using ARMv8 architecture, so the first task is to upgrade the ARMv8 to ARMv9.

Conclusion

As I scan through the SVE Programming Examples and the VLC source code, I cannot find a place to update the existing source code to SVE2 instruction set. Since SVE2 is also support SVE instruction set, the program will not break if we upgrade the architecture to ARMv9. Before I can provide further recommendation for SVE2 enhancements to VLC package, I need to have deeper understanding on SVE2 and the VLE source code first.

SPO600 Project Stage 2

Joyce Wei — Mon, 13 Dec 2021 04:58:34 +0000

Introduction

The open source package that I will be discuss in this blog is VLC. According to the official GitHub, VLC is a media player and multimedia engine that has been ported to different computing platforms. VLC can play various multimedia files, discs streams, allows playback from devices, and ids able to convert to or stream in various formats.

There are 557 contributors in this project and the last commit to the project is on April 14, 2021. According to the official website, the total download number is 6,566,829 across all versions and OS.

SIMD

In the file vlc_cpu.h under the include folder, we can see the CPU compatibilities of Neon and SVE for aarch64 system are specified in this file where Neon and SVE are different naming of SIMD.

There is a file named merge_arm64.S, we know that arm64 is other name for aarch64 and this file is there to add build system support / CPU detection for aarch64 SIMD system.

SPO600 Project Stage 1

Joyce Wei — Thu, 02 Dec 2021 04:59:29 +0000

Introduction

In this project we are benchmarking digital sound programs on both x86_64 and AArch64 systems.

There will be six programs (vol0.c to vol5.c) in total to be testing and they are just different approach to the same problem. Two of them will be specific to x86_64 system only.

Prediction

I am predicting the vol4.c program will have better performance because it is using SIMD optimization through inline assembly.

Benchmarking

The following are the results from each program. We can see that the programs don't produce the same output and there is a significant difference in vol3.c program.

I will be using 500000000 samples to test the programs and the results in following screenshot are the time taken to scale the samples.

According to the result, it takes approximately 1.5 seconds to scaling 500000000 sound samples using a x86_64 system. But when the results from AArch64 is much better than x86_64 even without SIMD optimization.

Memory Usage

vol0.c

vol1.c

vol2.c

vol3.c

vol4.c

vol5.c

Compiler Option

To increase the performance of the program, we can add compiler option -O2, -O3, -Ox via the Makefile.

Questions

Q: What does this next block do? Why?

The code block is checking if the system architecture is AArch64. If the system is AArch64 then compile vol0 to vol5. Otherwise, only compile vol0 to vol3 because vol4 and vol5 are specific to AArch64 architecture.

Q: Why is this needed?

We are accumulating the total data are processed in SAMPLES array in each programs, so we can compare the result.

Q: Why is this needed?

This line is printing the result to the console.

SPO600 Lab3 - 6502 Assembly Language Math Lab

Joyce Wei — Mon, 01 Nov 2021 03:53:58 +0000

In lab3 we are making a kaleidoscope program using 6502 assembly language. The bitmap screen is break down into 4 quadrants and user will be able to draw pixels on second quadrant(top-left) using arrow keys on keyboard. The pixels drawn will be reflect to other 3 quadrants.

Result

Source Code

 ; zero-page variable locations
 define ROW     $20 ; current row
 define COL     $21 ; current column
 define POINTER     $10 ; ptr: start of row
 define POINTER_H   $11

 ; constants
 define DOT     $01 ; dot colour location
 define CURSOR      $04 ; purple colour


setup:  lda #$0f    ; set initial ROW,COL
    sta ROW
    sta COL
    LDA #$01
    STA DOT

draw:   jsr draw_cursor

getkey:
    ldx #$00    ; clear out the key buffer
    lda $ff     ; get a keystroke
    stx $ff

    cmp #$30
    bmi getkey
    cmp #$40
    bpl continue

    SEC
    sbc #$30
    tay
    lda color_pallete, y
    sta DOT
    jmp done

continue:   
    cmp #$43    ; handle C or c
    beq clear
    cmp #$63
    beq clear

    cmp #$80    ; if not a cursor key, ignore
    bmi getkey
    cmp #$84
    bpl getkey

    pha     ; save A

    lda DOT ; set current position to DOT
    sta (POINTER),y
    jsr draw_on_quads

    pla     ; restore A

    cmp #$80    ; check key == up
    bne check1

    dec ROW     ; ... if yes, decrement ROW
    jmp done

 check1:    
    cmp #$81    ; check key == right
    bne check2

    inc COL     ; ... if yes, increment COL
    jmp done

 check2:    
    cmp #$82    ; check if key == down
    bne check3

    inc ROW     ; ... if yes, increment ROW
    jmp done

 check3:    
    cmp #$83    ; check if key == left
    bne done

    dec COL     ; ... if yes, decrement COL
    clc
    bcc done

 clear: 
    lda table_low   ; clear the screen
    sta POINTER
    lda table_high
    sta POINTER_H

    ldy #$00
    tya

 c_loop:    
    sta (POINTER),y
    iny
    bne c_loop

    inc POINTER_H
    ldx POINTER_H
    cpx #$06
    bne c_loop

 done:  
    clc     ; repeat
    bcc draw


 draw_cursor:
    lda ROW     ; ensure ROW is in range 0:0F
    and #$0f
    sta ROW

    lda COL     ; ensure COL is in range 0:0F
    and #$0f
    sta COL

    ldy ROW     ; load POINTER with start-of-row
    lda table_low,y
    sta POINTER
    lda table_high,y
    sta POINTER_H

    ldy COL     ; store CURSOR at POINTER plus COL
    lda #CURSOR
    sta (POINTER),y

    rts

 draw_on_quads:     
    LDA POINTER ;; save the pointer to the
    PHA     ;; original location in top_left_quad
    LDA POINTER_H
    PHA

; top right quadrant
    LDA #$10
    CLC
    SBC COL
    CLC
    ADC #$10
    TAY
    LDA DOT
    STA (POINTER),y

    TYA
    PHA     ; save the y offset

; bottom left quadrant  
    lda #$10    ; load POINTER with start-of-row
    CLC
    SBC ROW
    CLC
    ADC #$10
    TAY

    lda table_low,y
    sta POINTER
    lda table_high,y
    sta POINTER_H

    ldy COL     ; store CURSOR at POINTER plus COL
    lda DOT
    sta (POINTER),y

    PLA
    TAY

; bottom right quadrant 
    lda DOT
    sta (POINTER),y

    PLA
    STA POINTER_H
    PLA
    STA POINTER

    RTS

 ; 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

color_pallete:
dcb $01,$02,$03,$04,$05,$06,$07,$08,$09,$0a

The subroutines:

"draw_cursor" is restricting the area where the cursor is allowed to go which is second quadrant only by setting the range of row and column to [$00 : $0F]
"draw_on_quads" is reflecting the pixels in the second quadrant to other 3 quadrants by storing a copy of the current position and adding the x or y offset to the cursor.

SPO600 Lab2 - Experiments

Joyce Wei — Mon, 01 Nov 2021 03:53:45 +0000

This section is going to modify the starter code in order to do some experiment with the bitmap.

Starter Code

    LDA #$00    ; set a pointer at $40 to point to $0200
    STA $40
    LDA #$02
    STA $41

    LDA #$07    ; colour number

    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 1 page
    LDX $41     ; get current page number
    CPX #$06    ; compare with 6
    BNE loop    ; continue until done the page

Experiment 1

    LDA #$00    ; set a pointer at $40 to point to $0200
    STA $40
    LDA #$02
    STA $41

    LDA #$07    ; colour number

    LDY #$00    ; set index to 0

loop:   
    TYA     ; experiment 1
    STA ($40),y ; set pixel at the address (pointer)+Y

    INY         ; increment index
    BNE loop    ; continue until done the page

    INC $41     ; increment 1 page
    LDX $41     ; get current page number
    CPX #$06    ; compare with 6
    BNE loop    ; continue until done the page

After adding "TYA" after the "loop" label and before the "STA ($40),y", there are 32 vertical lines with 16 different colours displayed on the bitmap.

This is because "TYA" means "Transfer Y to A" and our accumulator(A) is holding the colour. Since we are incrementing the Y register after "TYA", the colour will change every time the value of Y register is incremented. Moreover, there are only 16 colours available and the bitmap has 32 columns so the vertical lines will be displayed.

Experiment 2

    LDA #$00    ; set a pointer at $40 to point to $0200
    STA $40
    LDA #$02
    STA $41

    LDA #$07    ; colour number

    LDY #$00    ; set index to 0

loop:   
    TYA     ; experiment 1
    LSR         ; experiment 2
    STA ($40),y ; set pixel at the address (pointer)+Y

    INY         ; increment index
    BNE loop    ; continue until done the page

    INC $41     ; increment 1 page
    LDX $41     ; get current page number
    CPX #$06    ; compare with 6
    BNE loop    ; continue until done the page

The instruction "LSR" means "Logical Shift Right" which will shift every bits one position to the right, this will result the vertical lines with one pixel wider.

As we adding more "LSR" instruction, the wider the pixels will be.

SPO600 Lab2 - 6502 Assembly Language Lab

Joyce Wei — Mon, 01 Nov 2021 03:53:36 +0000

In lab2 we are going to draw borders around the bitmap screen with 4 different colours using 6502 assembly language.

Source Code

    LDA #$00    ; set a pointer at $40 to point to $0200
    STA $40
    LDA #$02
    STA $41

    LDA #$05    ; colour number: green
    LDY #$00    ; set index to 0

; draw green line at the top of the bitmap screen

top:    
    STA ($40),y ; set pixel at the address (pointer)+Y
    INY         ; increment index
    CPY #$20    ; 
    BNE top         ; continue until done the page


    LDA #$05    ; set page to 5
    STA $41     ; 

    LDA #$06    ; colour number: blue
    LDY #$E0    ; set index to starting index of last line in pg.5

; draw blue line at the bottom of the bitmap screen

bottom: 
    STA ($40),y ; set pixel at the address (pointer)+Y
    INY         ; increment index
    CPY #$00    ; 
    BNE bottom      ; continue until done the page


    LDA #$02    ; set page to 2
    STA $41     ; 

    LDY #$00    ; set index to starting index of pg.2

; draw yellow line to the left and 
; purple line to the right of the bitmap screen

sides:  
    CLC     ; clear carry to prevent accumulating of a value
    LDA #$07    ; colour number: yellow
    STA ($40),y ; set pixel at the address (pointer)+Y
    TYA     ; transfer y to a
    ADC #$1F    ; increment memory (a) by 1f (32 in hex = 1 line)
    TAY     ; transfer a to y
    LDA #$04    ; colour number: purple
    STA ($40),y ; set pixel at the address (pointer)+Y
    INY     ; increment y (to first index of next line)
    CPY #$00    ; 
    BNE sides   ; continue until done the page

    INC $41     ; increment 1 page
    LDX $41     ; get current page number
    CPX #$06    ; compare with 6
    BNE sides   ; continue until done the page

I have break down the process of drawing the borders into 3 parts.

loop "top" draws a green border at the top of the bitmap screen
loop "bottom draws a blue border at the bottom of the bitmap screen by setting the starting index to $05E0
loop "sides" draws a yellow border to the left and a purple border to the right of the bitmap screen by keep switching between the two colours and increasing the index of the current line.

SPO600 - 6502 Assembly Language Bitmap

Joyce Wei — Mon, 01 Nov 2021 03:53:22 +0000

During the introduction to 6502 assembly language lecture, we have first introduced with the X and Y registers and accumulator. Also, we have take a look into how to move around the bitmap and change the colour of the pixel .

In the following code, I have try to load 3 different colours into the accumulator and registers then draw 9 pixels into the bitmap as an excise on how to move the pixels around.

Result

Source Code

LDA #01
LDX #07
LDY #03

STA $0200
STX $020f
STY $021f

STA $0400
STX $040f
STY $041f

STA $05e0
STX $05f0
STY $05ff

Opcode
LDA: LoaD Accumulator
LDX: LoaD X register
LDY: LoaD Y register

STA: STore Accumulator
STX: STore X register
STY: STore Y register

SPO600 Lab1 - Code Review

Joyce Wei — Mon, 01 Nov 2021 03:53:03 +0000

The open source projects required a license which specifies the authorization that everyone in the community has in order to contribute and make change to the code.

In this lab, I will be look into two open source projects each with different licenses and observe the code review process on how the contributors can contribute to the project.

DuckDuckGo iOS Application

DuckDuckGo is an internet search engine that licensed under the Apache 2.0 license.

To contribute to this project, contributors can either report an issue or require to create a pull request with a fix in their GitHub page with detailed description stated. Once one of the reviewers has reviewed the code and approved the changes, the code will be merge into the main branch.

There are two participants in this pull request, one is the contributor and one is the reviewer. The whole process take up 3 days to add a JS prompts support to the application. The contributor creates the pull request first, then the reviewer will review the code and provide some feedbacks. Once the code is fixed and approved, the code will be merged into the main branch.

Mikro-Orm

Mikro-Orm is TypeScript ORM for Node.js application that licensed under the MIT license.

To contribute to this project, contributors can either report an issue or require to create a pull request with a fix in their GitHub page with description stated. Once the reviewer has reviewed the code and approved the changes, the code will be merge into the main branch.

There are two participants in this pull request, one is the contributor and one is the reviewer. The whole process only takes up less than an hour to fix a missing type issue. The contributor creates the pull request first, then the reviewer will review the code and request changes to the fix code. Once the code is fixed and approved, a code coverage comment bot will come and show the code coverage result in the comment then the fix code will be merged into the main branch.

Hello, Open Source.

Joyce Wei — Sat, 11 Sep 2021 03:48:11 +0000

About Me

Hi there, I am Joyce, a CPA (Computer Programming and Analysis) student at Seneca College. I am currently living in Toronto Canada.

Why OSD600?

OSD600 is a Open Source Development course. This course provides the opportunity for me as a student developer to get better understanding on how to use GitHub to managing and contributing to various open source projects. After the end of this course I will be gaining real world experience on collaborating with other developers and contributing to open source projects on GitHub.

Explore Repos

I am interested in accessibility related field and the query language Graphql. apollo-client is a package that helps you to build the client side of a web app with backend API server using GraphQL. I am learning GraphQL on my own time and I found that both Apollo server and Apollo client are really helpful and easy-to-use when building a GraphQL backend.