Exploring the RISC-V ABI on Linux

We are going to take a break from systems programming in C to explore how processors run our programs, specifically a RISC-V processor running Linux. Without diving too far into the philosophy of RISC-V, it is an entirely open architecture which has been gaining popularity since its introduction in 2014. This is the architecture we study at University of Tennessee for our Computer Organization class, which focuses on how computers work at a hardware level, and the lowest levels of software that sit on top of that hardware.

The concepts discussed here may not transfer directly to other operating systems or architectures, but most of the fundamentals will stay the same. The most important thing to understand here, is that compilers generate assembly and/or machine code, which interacts directly with the CPU. Gaining a better understanding of what instructions are generated from the high-level code that you write will help you write better software.

We will be using compiler explorer, which allows us to view the assembly generated from C code in a much more organized manner.

There are 5 types of registers that we need to be concerned with when writing and read assembly. Each has its own purpose, and you need to be careful how they’re used/saved throughout your code.

When you call a function in any higher level language it looks very simple. The arguments are passed within the parentheses, and if it returns a value you place that on the left-hand side of the equals sign. What is the computer doing to make this all work? This is the core of what is called calling conventions, which is an agreement between the hardware and the software that runs on it. A calling convention defines what registers (or stack space) should be used for function arguments, and where the return value(s) should be placed.

Calling conventions are different for each hardware architecture, but many of the concepts stay the same. We prefer to pass arguments in registers if available, because they are much faster than reading from main memory, or even cache. They also define how specific registers are used, s registers are callee saved, the return address is volatile, and how the stack should be set up and torn down.

When a function is called on a RISC-V CPU there are a few things that need to be set up.

1. Move the stack pointer, making sure to keep it aligned to 16 byte increments
2. Store the current return address on the stack
3. Prepare function arguments in registers
   1. If the function returns a struct its address should be allocated on the stack, then passed in a0
   2. Remaining function arguments (up to 8) are passed left-to-right in the next available a registers
   3. Floating point arguments can also be passed left-to-right in fa registers
4. Use the call pseudoinstruction to call a function be either its label or memory address
   1. The address of the current instruction, call, will be placed in the return address register
   2. Once the callee returns control flow will return to the next instruction
5. If the function returns a scalar value it will be placed in a0, with a floating point scalar being placed in fa0
   1. Struct return values will be in the position previously allocated for them
6. Perform any other work needed
7. Once the current function is ready to exit it loads its original return address back off the stack
8. The stack is then moved back to its original position
   1. If your function does anything with the stack it must be returned to the exact same position before you may return
9. The functions return value is loaded into the appropriate register
10. Finally, we jump to the return address

This example follows these exact steps in order to call any another function. As long as every function follows these exact conventions it will be able to call any other function without issue. Think about it like the rules of driving, as long as everyone stays on their side of the road, and follows traffic lights we shouldn’t have any issues.

But there are some cases where you may want to break these rules for speed or simplicity. If you’re writing assembly by hand nothing says you have to follow these calling conventions. In fact, if you’re only going to call other functions that you wrote yourself you can ignore any or all of these rules.

Having said that, the calling conventions do ensure software works together, so unless you really know what you’re doing, it’s best to stick to it.

When a function returns a struct, it writes the fields of the struct directly onto the stack from of that function it was called from (note: simple structs may discard the concept of a struct entirely, returning values directly in registers). So, constructors and initialization functions do not perform extra work by first creating a struct, and then copying it back to the caller.

Let’s start by looking at main for this example. The first section in red sets up our stack, storing our return address for later. The value 5 is then loaded in register a1, which is the first and only argument to the function ms_init. The compiler then moves the value sp + 8 into a0. Why would we care about a value 8 bytes after the stack pointer?

Like we said before, functions that return structs write their fields directly onto the stack. So by moving the value sp + 8 into a0 we give the address of the struct to the function. It is important to note that when returning structs, their address takes priority over function arguments, and thus will be placed before them. Now we can see what ms_init does with these values.

The first step is to find the square of side_length, which is easily accomplished by calling the “w” version of mul. This value is stored back into a1 which we then write to a0 + 0, the address of the return struct. The first field in a struct is at the same address as the struct itself. Both the remaining fields are filled with constant values that are first loaded into a4, then written 8 and 16 bytes after the address in a0 respectively. Finally, the function returns.

Back in main the values are on the stack exactly like we expected. We then load area into a5 by loading a word from sp + 8, which is where we asked the struct to be stored. The 64-bit value is then loaded into a4 and the 2 are added together. The last field is then fetched with lbu, which stands for load byte unsigned, 0 extending the 8-bit value to 32-bits. Finally, it is added to accumulator, which we conveniently store in a0, the return register in the calling convention.

The last step is to restore the return address from the stack, move the stack back to its original position, and jump to the address held in ra.

There we go! If you are ever confused as to how structs are returned hopefully this helps explain.

If you’ve ever worked with function pointers you probably know they can be confusing to write in C/C++. This is one of the concepts I think is actually easier in assembly than in C, which is probably an odd thing to say.

When we call a function using call all we are really doing is jumping to its address in memory. If you know about any of the jump instructions, that probably sounds familiar. Let’s see how function pointers translate to assembly.

Our first step is to load the memory address of the function in a register, in this case a5. Then we prepare our argument and finally call jalr, which jumps to program counter to the address held in its argument register.

Contrast this with calling the function by name, which produces a call instruction in the assembly.

These may look like they’re doing very different things, but call and jalr are more closely related than you might think. Both call and jalr are commonly referred to as pseudoinstructions, meaning that assembler will generate a different set of instructions when it sees either of these 2. But what does it generate?

Well, a jalr instruction with a single register will turn into jalr ra, rs, 0, which means, add 0 to the ra register, then jump to the address in rs. The reason this code is generated is so that when the called function returns, we return to this exact location, then increment the pc and continue on. Pretty simple right? Just like we would call another other function on our RISC-V machine.

On the other hand, a call instruction can do nearly the exact same thing with one distinct advantage, it can jump to labels directly, without having to first store the value in a register. This is because once the program is compiled down, a call instruction generates aiupc t1, 20-bit value and jalr ra, t1, 12-bit value. A lot more code that has to get generated, luckily you won’t have to write it yourself.

All this to say that calling a function by name/label, and jumping to an address held in a register (function pointer) are no different at the end of the day. You may even find function pointers easier to understand in assembly than you do in C/C++.