Programming in assembly

Reading Time: 4 minutes

Assembly is the programming language closest to a CPU. ‘Closest’ here means that the keywords in the language translate 1:1 into instructions done by the CPU. With other (higher lever) languages, there’s either an interpreter or compiler which unpacks the language and generates usually quite significantly higher number of instructions when the code is to be executed on a real CPU.

With assembly, you tell exactly the processor what you want done – at register level. Whereas higher level languages achieve a lot of operations by abstracting the ingredients into a function (subroutine) name, assembly is about the elementals of computation: manipulating bits, and registers (composed of 8, 16, 32, or 64 bits at a time) — essentially, one of the smallest storage units of digital computers.

The things we often learn as programmers is a bit more “sophisticated”, and rightly so! It’s good to work on a level we’re comfortable with.

All languages, deep down “enough”, will be compiled into assembly. For example, Java is compiled to Java bytecode, which is then run in a virtual machine called JVM. The JVM however has to eventually execute plain assembly. Same with all other languages.

A (high level) programming language can be either:

  • interpreted, or
  • compiled

The question between those two choices has mainly to do with: at which point does the conversion to machine language happen; is it “early on” (compiled languages), or during the execution (interpreted languages). Python is interpreted, while C language is a compiled language. C produces traditional executable files; whereas Python source code is run by passing the file to the Python interpreter.

Assembly is a good language to really get an understanding of what the computing hardware actually does. All modern computers are described with the van Neumann architectural model:

A computer simply can load binary values to registers; do comparison and the usual suspects like addition, subtraction, multiplication, and division; store the value back to RAM (memory); and do stuff like jump around in various parts of the code (the ‘IF… THEN’ equivalent).

At first the basic level of profiency in assembly is attained by learning the opcodes: what commands are available. In reality, even assembly commands are internally stored and executed as a sequence of microcode within the processor.

Think of registers as just 8-, 16- 32 or 64 bit variables. They are done in real gates, physical constructs in the CPU. So they “always exist”, fixed. Their value can be altered: you can load a number, or you can load a number (content) from a memory location. There are commands to

  • zero a register (make it 0)
  • add two registers (arithmetically sum)
  • subtract a register’s value from another register
  • multiply
  • divide a number in a register by another register
  • compare the values of registers (and take action: a jump = branch)

I did a lot of Intel x86 assembly programming as teen.

Is assembly really that hard?

Why does assembly have a hard-to-grasp reputation? It’s probably because of the very terse and “weird” vocabulary. Also compared to other languages, there’s so much of “nonsensical” stuff in assembly: why the heck do you “move the value 64778 to register this-or-that”.. It doesn’t seem to make any sense at all!

When you’ve learned to program in assembly, it all makes sense. But I have to admit that looking at some of the code now, in the year 2019 – that’s some 25 years later – I don’t recollect all the details anymore.

Let’s look at a image uncompression program. It’s a complete program, showing a RIX image on-screen. RIX is a format which is now almost extinct. It used to be quite popular in the wild, although very simple format. Because of being simple the .RIX was also a perfect training target for making a program that can interpret it.


Set_DTA proc near
mov ah,1ah
lea dx,new_dta
int 21h
Set_DTA endp

AllocMem proc near
mov ah,48h
mov bx,4096
int 21h
jnc yli1
disp_str nomem
end_prog 255
mov alseg,ax
ret AllocMem

DeAllocMem proc near
push es
mov ax,alseg
mov es,ax
mov ah,49h
int 21h
pop es
ret DeAllocMem

;; Find first file, matching the search mask string defined
;; in memory area pointed to by "maski"
FindFirst proc near
mov ah,4eh
xor cx,cx
lea dx,maski
int 21h
FindFirst endp

;; After we have called once the FindFirst proc,
;; continue giving next results using the same search mask string
FindNext proc near
mov ah,4fh
int 21h
ret FindNext

LoadRIX proc near
lea dx,dta_name
call open_file
mov kahva,ax
mov bx,ax
call begin_file
mov bx,kahva
mov cx,64778
xor dx,dx
push ds
mov ax,alseg
mov ds,ax
call read_file
pop ds
mov bx,kahva
call close_file
LoadRIX endp

SwitchPic proc near
push ds es
mov ax,0
mov w1,ax
mov w2,ax
mov ax,alseg
mov es,ax
mov cx,3
in al,60h
loop plp
mov si,w1
add si,w2
cmp si,030ah
jb eikay
cmp si,0fd09h
ja eikay
mov al,byte ptr [es:si]
push ds ax
mov ax,0a000h
mov ds,ax
pop ax
mov byte ptr [si-030ah],al
pop ds
inc word ptr [w1]
cmp w1,0ffffh
jne yli3
pop es ds
mov ax,w1
add w2,ax
jmp spl
SwitchPic endp

ClearBuf proc near
push es
mov ax,alseg
mov es,ax
xor si,si
xor ax,ax
mov word ptr [es:si],ax
add si,2
cmp si,0fd10h
jb cbl1
pop es
ret ClearBuf

mov ax,tieto
mov ds,ax
call Set_DTA
call FindFirst
jnc yli2
disp_str norix
end_prog 255
call AllocMem
mov ax,13h
int 10h
call LoadRIX
push es
mov ax,alseg
mov es,ax
mov dx,000ah
xor bx,bx
mov cx,256
call SwitchPic
call FindNext
jc ulos
get_key 0
cmp al,27
je immed
jmp newpic
get_key 0
call ClearBuf
call SwitchPic
mov ax,3
int 10h
call DeAllocMem
mov ax,0c06h
mov dh,0ffh
int 21h
end_prog 0

w1 dw 0
w2 dw 0
maski db '*.rix',0
nomem db 'Not enough free memory (64K) to run program!$'
norix db 'No .RIX files found in current directory!$'
alseg dw 0 kahva
dw 0 new_dta db 30 dup(0) dta_name
db 13 dup(0) TIETO
END prosed

Open source, closed doors? Peace of code.

Reading Time: 2 minutesThroughout my involvement with code, I’ve been curious as to both the volume and quality of code. As well as, how it feels in particular moments to be programming.

Not so long time ago the suitability of open-plan offices to R&D (generally, “anything needing precise concentration for rather long periods of time”) was revisited and, according to many articles or persons, programmers hate open-plan offices. This in turn translates to diminished productivity.

Part of the negative side of a open-plan office is due to interrupting the flow, or optimal mental state of a developer. Good managers know how to shield developers from completely unnecessary and fruitless disruptions. Apart from one-man shops (where you, the CEO, are also developers, sales-guy, coffee grinder and the janitor), developers rarely should directly handle individual service cases (ie. being helpdesk), nor should they have much direct daily output to sales activity. Developers often participate as technical aides in product design; write both payload code and tests (the ‘core’ of their trade), handle open bugs, and learn new things. Developers should not (in my opinion) be involved much in the back-office activities of a project, such as maintaining capacity and reliable availability of servers, configuring complex build systems; and they definitely should not be involved in mindless ramifications from organizational architecture change such as moving a lot of stuff from a folder to another, or having fencing with any office productivity / email / calendar suites. Well, the latter goes to every role (not just devs) in the company, and I know that it’s part idealistic to state that change shouldn’t incur painful and numbing experiences.

My stance on the open-floor plan issue is quite similar as the news. If I’m mostly in developer role, I prefer somewhat closed rooms. It doesn’t mean that each developer would sit in their own closet, but rather that a team is shielded from extraneous noise and distractions. A very good idea is to have easily available, temp quiet spaces for individual work. Booking them shouldn’t be necessary.

Joel Spolsky said very well:

The more things you (ie. developer) can keep in your brain at once, the faster you can code, by orders of magnitude.

There might be purely neurological reason behind this. Our sound perception works as a background thread, automatically. We kind of – computationally speaking – keep making sense of the word-stream that enters our ears. Thus the more there is sound signal in the enclosing space, the more we probably have to deviate from perfect concentration on the most important task.

The idea behind open-floor plans probably were to alleviate siloing (individual developers going solo, making things that become incomprehensible to others, and pose a business risk). By putting people together, the architects maybe thought of leveling and making the team advance in more even and predictable steps. Reality perhaps got in the way.