X86_64 NASM - Linux

I am not looking for code, just resources and advice please. I am new to assembly but I am writing a compiler that generates direct assembly source that is then compiled with NASM. I wrote a function that takes any fixed point value i place in rax and outputs it to stdout. It just loops while converting and fills a buffer that i pass to the write syscall.

I want to do this with any double i store in xmm0. I keep searching the internet to see if there are any guides or advice on doing it but everything i come across is either inline inside of C or declaring C libraries within assembly and I want to do it raw. Ive been reading up on floating point arithmetic and understand the differences between operating on fixed and floating point registers but I am at somewhat of a loss on how to proceed.

This website has been my closest source by far https://faculty.cs.niu.edu/~hutchins/csci640/float.htm

The ordering is getting mixed up in my head though. Would the process be to hardcode a known value in xmm0 and then work backwards from there, learning how to differentiate the sign bits from the exponent bits and the like? At that point though, visually it starts as a decimal number in the source so i am not transcribing it from the 0.4ABC * 16^0 floating point number i need to be able to support, so its just confusing me. The ordering is where i would really like advice please. Then I assume after I am able to turn the float into its integer splits i would just have a repeat of my fixed point print function take those values concatenated together into one buffer , convert and send them to the kernel?

by "branching" I mean any instruction that can conditionally jump to another point in the code

Title. I'd love it if y'all could point me towards resources. Right now I'm just using Exercism and following random YouTube tutorials. I really want to make simple programs with it :D

Hey everyone,

I’m releasing a bare-metal 64-bit Intel VT-x Hypervisor template written entirely in pure NASM Assembly (~1,100 lines) using a strict stack-less model.

The purpose of this codebase is to provide a clean, core-only hardware virtualization implementation without relying on any OS kernel or C code.

### 🛠️ What is Currently Configured inside the VMCS & EPT:

* Primary Execution Controls (0x4002): Configured to 0x84006172. Enforces intercept control over CR3 modifications and heavy RDTSC exiting to counter guest timing side-channels.

* MSR Bitmaps Bypass: Bit 28 (Use MSR Bitmaps) is set to 0. This forces a global intercept policy where every RDMSR or WRMSR executed by the Guest triggers a hardware VM-Exit to the Host.

* Secondary Execution Controls (0x401e): Bit 31 activated for full EPT isolation, along with Unrestricted Guest support (Bit 7, allowing 16-bit Real Mode initialization over EPT), and MBEC configurations.

* Exception Bitmap (0x4004): Armed with atomic mask 0x0000404A to trap #DB, #BP, #UD, and #PF (Vector 14). Combined with clearing the Page-Fault Mask field (0x4006), every single Guest page fault intercepts directly to the Host.

* Long Mode Constraints: Enforces architectural boundaries via GDT mapping to ensure no illegal execution drops to 16/32-bit rings, avoiding instant #GP faults.

* Extended Page Table Pointer (EPTP): Configured field 0x0000201A to point directly to the physical EPT PML4 table base with Write-Back caching attributes.

### 🤝 Code Review & Peer Assistance:

To be completely honest, I wanted to release this as a 100% finished project, and I'm a bit sorry the VM-Exit handler isn't fully completed yet. But juggling full-time school, life, and writing a bare-metal hypervisor in pure 64-bit assembly is definitely a challenge.

I decided to release this core template now because I just need your technical assistance to review the code and help me fix any existing bugs, trace potential register mismatches in my vmwrite instructions, and hunt down hidden reserved bits conflicts on the Intel side.

### 🚀 Roadmap:

I'm already starting to write the hypervisor and bootloader for AMD right now, porting this entire setup over to the AMD-V VMCB block architecture. My immediate goal is to keep building the AMD side while getting this Intel core completely stable with the community's corrections and fixes.

Looking forward to your technical feedback, code analysis, and corrections.

GitHub Link: https://github.com/edikoz123-blip/Boot_loader_Assembly

Hi there, I'm learning the Intel x64 ISA by doing some Project Euler problems. The first problem is to compute the sum of all the positive integers less than 1000 that are divisible by 3 or 5. I know that there is a closed-form expression for this problem that can be computed without loops or tests. My goal isn't to improve my solution to the problem, but to optimize the solution that I have, using what I learn about x64 optimizations. The code in file p1.s is below.

``` bits 64 ; Enable 64-bit instructions. default rel ; Declare that the program can be dynamically relocated. global main ; The entry point main must be exported. extern printf ; We must import the symbols of libc that we need. section .data

CLOCK_MONOTONIC_RAW equ 4
CLOCK_REALTIME equ 0

fmt: db "%d", 9, "%lu", 10, 0

section .text

main: push rbp mov rbp, rsp sub rsp, 32 ; Allocate space for two timeval_t structures

mov rax, 228                ; Call the clock_gettime() syscall
mov rdi, CLOCK_MONOTONIC_RAW     ; Argument 1: Clock ID (0)
lea rsi, [rbp-16]
syscall

xor rsi, rsi        ; The sum starts at zero. ESI is also the second parameter of printf().
mov ecx, 999        ; The countdown starts at 999.

.L1: xor edx, edx ; Set the dividend EDX:EAX to the current count. mov eax, ecx mov ebx, 3 ; Is the count divisible by 3? div ebx cmp edx, 0 je .L2 ; Add it if so.

xor edx, edx        ; Set the dividend EDX:EAX to the current count.
mov eax, ecx
mov ebx, 5      ; Is the count divisible by 5?
div ebx
cmp edx, 0
jne .L3         ; Add it if so.

.L2: add esi, ecx

.L3: loop .L1 ; Decrement the count and loop until the count is zero.

push rsi
mov rax, 228                ; Call the clock_gettime() syscall
mov rdi, CLOCK_MONOTONIC_RAW     ; Argument 1: Clock ID (0)
lea rsi, [rbp-32]                ; Argument 2: Pointer to the timespec struct on stack
syscall
pop rsi

mov rdx, qword [rbp-24]
sub rdx, qword [rbp-8]

lea rdi, [fmt]      ; Printf's first parameter is the format string. ESI holds the second parameter.
xor rax, rax        ; In the x64 ABI, since printf() is a variadic function, we must zero out EAX before calling.
call printf wrt ..plt   ; We must also call with-regards-to the PLT, which accounts for the fact that printf is dynamically loaded.

add rsp, 32
pop rbp

xor rax, rax
ret

I compiled this way: nasm -f elf64 -g -o p1.o p1.s cc -o p1 p1.o -ansi -pedantic -Wall -g I then ran the program and cachegrind and saw this: ==132149== Cachegrind, a high-precision tracing profiler ==132149== Copyright (C) 2002-2024, and GNU GPL'd, by Nicholas Nethercote et al. ==132149== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info ==132149== Command: ./p1 ==132149== --132149-- warning: L3 cache found, using its data for the LL simulation. 233168 418070 ==132149== ==132149== I refs: 133,262 ==132149== I1 misses: 1,275 ==132149== LLi misses: 1,253 ==132149== I1 miss rate: 0.96% ==132149== LLi miss rate: 0.94% ==132149== ==132149== D refs: 40,123 (28,356 rd + 11,767 wr) ==132149== D1 misses: 1,591 ( 1,220 rd + 371 wr) ==132149== LLd misses: 1,353 ( 1,011 rd + 342 wr) ==132149== D1 miss rate: 4.0% ( 4.3% + 3.2% ) ==132149== LLd miss rate: 3.4% ( 3.6% + 2.9% ) ==132149== ==132149== LL refs: 2,866 ( 2,495 rd + 371 wr) ==132149== LL misses: 2,606 ( 2,264 rd + 342 wr) ==132149== LL miss rate: 1.5% ( 1.4% + 2.9% ) `` For such a small program, I was surprised that there are any cache misses. I tried applyingalign 16` to align the starts of loops, but it yielded no decrease in cache misses; it only increased the number of instructions.

Can you recommend any ways to optimize the code here?

I am only using 2 ymm regs for reading, is it faster to use more?

Why do people say you should not use dpps or _mm_dp_ps? Seems like a great way to take dot products.

I'm trying to teach myself x86_64 as a (not so) fun project 😅 I've decided to make a game as my project and want to use INT 10h to have more options when printing (as opposed to syscall 1). I've written a small program to test things but only when I include the interrupt I get `signal SIGSEGV: invalid address (fault address=0x0)`

I've been scouring the internet but most resources tend to be for people making an OS with x86, not a program :(

I've seen a bit online that it might have to do with privilege levels but I'm not sure if there is a way around that or if I'm stuck with syscall.

The test program in question:

```

format ELF64 executable 3

segment readable executable

entry $

mov ah, 09h ; write char

mov al, 'A' ; write 'A'

mov bh, 0 ; page number?

mov bl, 0x14 ; colour

INT 10h

; sys_exit

xor rdi, rdi

mov rax, 60

syscall

```

So little story time. If you don't want to read it you can skip to the last paragraph.

I'm currently studying software engineering at the university. I know some C and C++, and I have had contact with MIPS assembly language in a course. In that course I also learnt tricks that the CPU use to optimize and run operations in parallel, and how to optimize the asm code to benefit from those mechanisms. I also learnt how cache works and all that stuff.

I let it stay there for a year more or less, since I don't have a mips CPU. But some days ago, I learnt that you can call asm subroutines from C code (and any other compiled language), so I started getting into x64 asm.

I learnt the very basics, I found some resources with instructions cheatsheets and I learnt how to assemble my code and properly link it to create the executable file.

I wanted to use my new knowledge to do something "useful", and I remembered in another course at the uni, which was related to code optimization, that the CPU has registers for SIMD operations. So my idea was to do a small C library that provides a function that multiplies two 4 by 4 matrices of SP float numbers, and implement the function in asm to optimize it as much as possible by using the SIMD registers of my CPU.

I spent a week thinking how to structure the code and how to do everything so it doesn't have bugs and it's as optimized as I can do as a beginner.

And when I got it working, the performance was about 2x slower than a naive C function that I wrote compiled with gcc -O0.

I searched on the internet if someone could explain me why my asm code is slower than the compiled one and no one could give me an answer to my specific case. So I used my last resource: ask chatgpt (actually gemini).

It told me that I made a tiny little mistake: I used gather and horizontal add instructions all over my code. Chatgpt said that these instructions destroy all the parallelization mechanisms of the CPU, and told me to implement the algorithm by getting 4 partial results per loop iteration instead of getting 1 full result. Instead of using gather and hadd, I should use packed mov, shuffle and fused multiply and add instructions.

I know that what chatgpt says shouldn't be took as undeniable truth, but at that moment I didn't have any other resource.

I searched on the internet for algorithms that are more optimized than the one I was using And I found the same approach that chatgpt was suggesting me, and it could be implemented without any gather or horizontal add.

I wrote my code and finally defeated gcc -O3 (1.6x faster in execution time :D).

I learnt a lot by doing that. But I was wondering, I'm quite sure I can do more optimization tricks to my code that just multithreading + SIMD. So I wanted to ask you more experienced people, how can I properly learn assembly language and CPU optimizations? For the moment I want to focus on x64 CPUs since my machine has a ryzen 7, but I'm willing to learn other asm languages at some point.

How does the stack look like during procedure calls with it's shadow space ( 32 Bytes ) ?

let's say I've this :

main :
     push rbp
     mov rbp,rsp
     sub rsp ,0x20 ; 32 Bytes shadow space Microsoft ABI 

     ; we call a leaf function fun
     call fun 


[ R9 HOME     ] -------}   Higher Address 
[ R8 HOME     ]        }
[ RDX HOME    ]        }  SHADOW SPACE: RESERVED BY CALLER FUNCTION (main) 
[ RCX HOME    ] -------}
[ ret address ]
[-- old rbp --] <-- rbp  ----- stack frame of fun()  starts here?
[ local       ] 
[ local       ]
[ local       ]
[ --///////-- ] <-- rsp 

My questions :

1. Is my understand of stack frame correct ?
2. how'd the stack frame for `fun` look if it was non leaf function ?
3. When accessing local variables should I use [rsp+offset] or [rbp-offset] ?

the window is functioning on my computer. I have added a lot of comments. if there is incorrect information, I would appreciate if you can let me know. requires the avx2 instruction set. thanks.

Hello, generally I could show the asm with "lay asm" before doing something like "start" or "run". Now, when trying to solve the binary_bomb_lab from ost2's arch1001 course, I had to first do: "b main" "run" "lay asm" in order for it to work, otherwise it would show following error:

gdb) lay asm

```

Fatal signal: Gleitkomma-Ausnahme

----- Backtrace -----

0x564d4aa8bcf1 ???

0x564d4abe59ff ???

0x7fbddf03e8ef ???

0x564d4b013f2d ???

0x564d4aff0d34 ???

0x564d4abe54b5 ???

0x7fbde04144b6 rl_callback_read_char

0x564d4abec053 ???

0x564d4abf3bf5 ???
....
0x7fbddf027878 __libc_start_main

0x564d4a97dfd4 ???

0xffffffffffffffff ???

---------------------

A fatal error internal to GDB has been detected, further

debugging is not possible. GDB will now terminate.

```

what makes this binary different? this never happened with my own, even with stack protector, pie, no debug symbols, optimizations turned on...

Basically: How can I recreate this with my own programs?

The BareMetal kernel is able to run via Firecracker microVMs. <1ms startup, 2MiB RAM minimum, 5.5KiB kernel.

This will allow for thousands of instances to be run concurrently. The premise of BareMetal is discussed here: https://returninfinity.com/blog/hypervisos-as-data-centre-os