Skip to main content

Assembly?


Photo by Jonas Svidras on Unsplash

 Last week on my SPO course, I had my first experience writing Assembly code. I won’t lie; it was struggling. For me, Assembly is like the Latin of the codding languages and “carpe diem” wasn’t my first lesson. Hexadecimal, binary and a list of instructions is a must know to guarantee survival.

Our instructor introduced us to the 6502 processor: it is an old school chip that was used in many home solutions such as PCs and video games. Internally, it has three general-purpose registers, three special-purpose registers, memory and input and output ports. Fortunately, there are emulators on the internet that helps us to focus on the development, hiding the electronic part from us.

http://6502.cdot.systems/

Using the emulator, our first task was to copy, paste and execute a piece of code to change the colour of every pixel in the display matrix. That was easy! The result was a yellow screen. Then we were asked to introduce some instructions at specific points in the code. Every change in the code changed the filling pattern in the display.

lda #$00 ; set a pointer at $40 to point to $0200
sta $40
lda #$02
sta $41
lda #$07 ; colour
ldy #$00 ; set index to 0
loop: sta ($40),y ; set pixel
iny ; increment index
bne loop ; continue until done the page
inc $41 ; increment the page
ldx $41 ; get the page
cpx #$06 ; compare with 6
bne loop ; continue until done all pages
view raw spo-lab1.s hosted with ❤ by GitHub


The first modification was small: add tya after the loop. It changed the display from plain yellow to 16 vertical-coloured strips repeated side by side. Then, adding lsr, altered the size of the bands, and the repeated pattern disappears. After that, we went crazy, adding multiple lsr, switching tya to asl, and others. They changed the filling pattern, the pixel colour and sometimes both. Those exercises introduced us to the loop and nested loop using Assembly.

Then we increase the level of complexity! We had to place a line on the top and at the bottom of the screen. Easy? Not really. I struggled to define the beginning of the last line and the number of pixels to fill in. Yes, I know how to count, but that thing only understands hexadecimal! So, 32 in hex is $20. The bottom was more challenging, though. The whole display has 4 pages; every page has 4 lines, and every line has 32 pixels. So, to get the start from the bottom, I needed the last page ($05) plus 32x3 pixels. In hex, please! The answer is $05E0. Then I put it in the loop, set the right colour for each one and run it successfully.

lda #$00 ; set a pointer at $40 to point to $0200
sta $40
lda #$02
sta $41
lda #$07 ; colour
ldy #$00 ; set index to 0
loop: lda #$05 ; colour - green
sta $0200,y ; set pixel top
lda #$06 ; colour - blue
sta $05E0,y ; set pixel bottom
iny ; increment index
cpy #$20 ; compare with 20
bne loop ; continue until done the page
view raw spo-lab2-1.s hosted with ❤ by GitHub


When I thought that it was enough for the first Lab, the last task made me grab a coffee. It was to draw simple lines as the previous, but this time, on the left and in the right. My first approach was to use a second loop that steps 32 pixels at a time. But this doesn’t help when we need to change the page. Fortunately, I attended the last lecture class, and our instructor explained how to accomplish it.

define POINTER $40
define POINTER_H $41
lda #$00 ; set a pointer at $40 to point to $0200
sta $40
lda #$02
sta $41
lda #$07 ; colour
ldy #$00 ; set index to 0
loop: lda #$05 ; colour - green
sta $0200,y ; set pixel top
lda #$06 ; colour - blue
sta $05E0,y ; set pixel bottom
iny ; increment index
cpy #$20 ; compare with 20
bne loop ; continue until done the page
; --- Left side ---
lda #$00
sta POINTER
lda #$02
sta POINTER_H
ldy #$00
left: lda #$07 ; colour - yellow
sta (POINTER),y
lda POINTER
clc
adc #$20 ; increment by 32
sta POINTER
bcc left
inc POINTER_H ; change the page
lda POINTER_H
cmp #$06
bne left
; --- Right side ---
lda #$1F
sta POINTER
lda #$02
sta POINTER_H
ldy #$00
right: lda #$04 ; colour - purple
sta (POINTER),y
lda POINTER
clc
adc #$20 ; crement by 32
sta POINTER
bcc right
inc POINTER_H ; change the page
lda POINTER_H
cmp #$06
bne right
view raw spo-lab2-1.s hosted with ❤ by GitHub


To conclude, Assembly is not a dead language. It is the second language spoken by every processor when they get out of the factory. You must know it if you want to talk face to face with them. Or perhaps you want a closer relationship; you should learn their first language – binary. However, if you speak C, C++, Java or others, it is also possible to have a conversation by using “translators.” The compilation process will translate everything for us. Just like human language, sometimes the translators give us bad sentences. The meaning is there, but we need to take some time and effort to process it. The same happens with our fellow processors.

Labels

Labels:

Comments

Post a Comment

Popular posts from this blog

Going Faster

Photo by  Anders Jildén  on  Unsplash Today’s topic is compiler optimizations. Besides translating our source code into machine binary executable, the compiler, based on optimization parameters, can also produce faster executables. Just by adding some parameters to the compiler, we can get a better performance or a smaller executable, for example. There are hundreds of those parameters which we can turn on or off using the prefix -f and -fno. However, instead of doing one by one, we can use the features mode using the -O param. It ranges from 0 (no optimization – the default) to 3 (the highest). Using those parameters has a cost —usually, the faster, the larger executable. How does the compiler make it faster if my code is perfect? I’m going to put some methods here, but if you want, here is more detail . Also, bear in mind that most of the optimizations are done in the intermediate representation of the program. So, the examples below are rewritten just to...
Post a Comment
Read more

Hello World in Assembly

Photo by  Martin Sanchez  on  Unsplash Assembly alert! I promised to talk more about the compiler, but before it, more assembly. It is for a good reason, though. I was surprised to see my professor doing the “hello world” in assembly! Not only on x86_64 but also in the ARMv8 – different source code. He coded just like C or C++, saved, compiled and run it. The output was exactly like any other language. Nobody knew, but he was doing the Lab 5! I wish I were recording it. Our goal in this class was to compare the compiler output with the hand-crafted assembly. As expected, the compiler produced non-optimal executables even when we played with some fine-tuning options that I mentioned in the last post. How to compile an assembly code? Here are the commands: - Using GNU Assembler > as -g -o test.o test.s > ld -o test test.o - Using NASM Assembler > nasm -g -f elf64 -o test.o test.s > ld -o test test.o - Using GCC > gcc -g -o test.o test.S ...
Post a Comment
Read more

SIMD - Single Instruction Multiple Data

Photo by  Vladimir Patkachakov  on  Unsplash Hi! Today’s lecture, we learned SIMD - Single Instruction Multiple Data. This is a great tool to process data in a bulk fashion. So, instead of doing one by one, based on the variable size, we can do 16, 8, 4 or 2 at the time. This technique is called auto-vectorization resources, and it falls into the category of machine instruction optimization that I mentioned in my last post. If the machine is SIMD enabled, the compiler can use it when translating a sum loop, for example. If we are summing 8 bits numbers, using SIMD, it will be 16 times faster. However, the compiler can figure that it is not safe to use SIMD due to overlapping or non-aligned data. In fact, the compiler will not apply SIMD in most cases, so we need to get our hands dirty and inject some assembly. I’ll show you how to do it in a second. Here are the lanes of the 128-bit AArch64 Advanced SIMD: 16 x 8 bits 8 x 16 bits 4 x 32 bits 2 x 64 bits 1 x ...
Post a Comment
Read more