A few x86_64 assembly tips

[macpacheco]

1 - Don't push the same register multiple times.
push rax
push rax
do something
pop rax
do other stuff
pop rax

Instead:
push rax
do something
mov rax, [rsp] ; take the value from the top of the stack
do other stuff
pop rax

If you need access to the next item on the stack, then [rsp+8] will do.

2 - Write position independent (relocatable) code:
I - lea register, [symbol] instead of mov register, symbol
II - put: "DEFAULT rel" in the top of the file, and all accesses like mov register, [symbol] become rip relative without having to change the code. But you need to use [abs symbol] when symbol if fixed in memory rather than a symbol inside the same binary. For instance: call [abs b_output]. LEA using relative address saves a few bytes per instruction (because the relative addressing is 4 bytes wide vs 8 bytes when you load an abs address into a register).
III - If you do it right, the ORG directive becomes irrelevant.
I'm converting monitor and tools to relocatable code. As soon as I'm done I'll post the code.

3 - You can multiply a register on the fly for relative addressing, saving some instructions.
mov rax, [rbx+rsi * 8]
mov [rcx+rdi * 8+offset], rdx
Only rsi and rdi can be multiplied, and only by 1,2,4,8.
https://blog.yossarian.net/2020/06/13/How-x86_64-addresses-memory

Unrelated:
I've been converting BareMetal code to C. My current code is really ugly, so I'm not ready to share yet, I've got AHCI,IDE and E1000 drivers working. With interrupts for AHCI. I can glance at C code and understand exactly what it does, but assembly is so much harder to read.

[IanSeyler]

You are correct.

1. Ideally we should write to the stack as little as possible. There are a few functions that would benefit from this. It's just something that needs to be documented in the code in case major changes are made later (pushing something else to the stack).

2. Agreed. Just keep in mind that some structures (IDT, GDT, PML4, etc) are built in specific locations and the kernel depends on it. For monitor and the apps this doesn't really apply and is a great idea.

3. Good call!

Regarding a rewrite to C. You may want to look into using Limine as the boot loader. I tried this earlier in the week and it was pretty straightforward - https://github.com/limine-bootloader/limine-c-template

[macpacheco]

Here's what I did on the C idea:
1-Move the entry points to the Pure64 area:
b_input equ 0x0000000000005200 ; Scans keyboard for input. OUT: AL = 0 if no key pressed, otherwise ASCII code
b_output equ 0x0000000000005208 ; Displays a number of characters. IN: RSI = message location, RCX = number of characters
b_net_tx equ 0x0000000000005210 ; Transmit a packet via a network interface. IN: RSI = Memory location where packet is stored, RCX = Length of packet
b_net_rx equ 0x0000000000005218 ; Polls the network interface for received packet. IN: RDI = Memory location where packet will be stored. OUT: RCX = Length of packet
b_storage_read equ 0x0000000000005220 ; Read data from a drive. IN: RAX = Starting sector, RCX = Number of sectors to read, RDX = Drive, RDI = Memory location to store data
b_storage_write equ 0x0000000000005228 ; Write data to a drive. IN: RAX = Starting sector, RCX = Number of sectors to write, RDX = Drive, RSI = Memory location of data to store
b_config equ 0x0000000000005230 ; View/modify configuration. IN: RCX = Function, RAX = Variable 1, RDX = Variable 2. OUT: RAX = Result
b_system equ 0x0000000000005238 ; Call a system function. IN: RCX = Function, RAX = Variable 1, RDX = Variable 2. Out: RAX = Result 1, RDX = Result 2

2-Baremetal now starts with 2 qwords, offset for code entry point / size of the file.

3 - pure64.asm for me ends with:
EOF:
db 0xDE, 0xAD, 0xC0, 0xDE
align 16
KERNELADDR equ $

The jmp 0x100000 was replaced with:
mov rax, [KERNELADDR]
add rax, KERNELADDR
jmp rax ; initial jump point is KERNELADDR + [KERNELADDR]

This takes care of allowing a relocatable BareMetal.

4 - On BareMetal C edition:
startup.s:
.intel_syntax noprefix
.section .text
.align 16
.globl header
header:
.quad main-$ # Relative address to startup code
.quad __bss_start-$ # Size of this binary

// ld scripts define symbols not values, so only taking their addresses make sense
extern u64 __bss_start;
extern u64 __bss_stop;
// The "address" of __bss_size is the number of QWORDS in BSS
extern u64 __bss_size;
extern u64 __load_addr; // Start of the executable
extern u64 __file_end; // Start of the executable

on the main() function:
// Move monitor from the loaded location (__bss_start) to the lowest safe location (__bss_stop)
mem8cpy((u64*)&__bss_start, (void *)&__bss_stop, 2048L); // Move from __bss_start to __bss_stop, 16KB (2K qwords).

I only expect Pure64 and BareMetal to be 16 byte aligned.

Only today I managed to get monitor and a few apps running properly with PIE code (BareMetal C and Monitor in Assembly, all PIE).

Accessing absolute address from PIE code is easy, both from C and assembly.
From C. For now I'm only changing IDT and 0x5000 area, which I address with absolute addresses (I define a C struct for each and cast the 0x0/0x5000 address into a struct *). That's easy peasy.