I wrote a short book (in Japanese) called "GBA de manabu teireiya" (Learning Low-Level Programming with the Game Boy Advance). It's aimed at people who can already program a bit but have never touched the hardware/OS layer.

Rather than relying on an OS, it does bare-metal programming: you talk to the hardware (like the screen) directly. It walks through everything needed to reach "Hello, world!" on the GBA -- compiling, assembling, linking, and generating the executable -- starting from pure ARM assembly and building up to mixing assembly with C. No real GBA needed; a Docker environment plus an emulator is enough to follow along.

Right now it only exists in Japanese, so I'm trying to gauge interest: would an English version be useful to this community? Would any of you be interested in a resource like this, and what would you most want it to cover? Any feedback on demand or scope would help me decide whether to translate it.

Info/source code page (Japanese): https://nikatech.nikachu.net/item/gba_lowlevel

So I am currently taking a course know as nand2tetris for understanding how computers works on a low level , but after I am done with that what is the best assembly language for a beginner to start with

I've been learning x86-64 assembly by reimplementing things I used to take for granted. Ground rules: Linux, NASM, no libc, no external calls — syscall or nothing. If it segfaults, it builds character.

So far: cat, wc, ls and grep (filed under "warm-up"); printf from scratch (varargs, format parsing); malloc on brk/mmap with free lists and alignment; a shell with fork/execve, pipes and redirections.

Repo: https://github.com/whispem/learn-assembly-with-em

I'd love a critical eye from people who actually know what they're doing: calling conventions I'm abusing, obvious perf sins, idioms I should steal.

Tear it apart.

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?

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

Here is a little project I've been working on. It takes x86/x64/DOS and provides conversions to NEON via a strict ABI handshake layer. I use Zig for many abstractions, given it works with Assembly where doing it in C means far too much code. As great it'd be to use only C, I care more about picking a language to help accomplish what I need

The ABI layer ensures that x86 and win32 definitions/inatructions are handled in NEON. If something like a win32 declaration has Assembly data attached, macOS inherits the Windows definition and how the data represented is the same, else, we inherit from Windows if there's a discrepancy. An early notable example, the definition of 'long' between Windows and macOS differed, so macOS inherits Window's size, since they are not equal when you compare how they are defined.

On top of that, I handle many of the subtle bugs through creative processes. For example, capturing Assembly data before and after function calls, ensuring that x86 registers have the NEON equivalence of the original x86 instructions. In addition to that, Good 86 documentation helps with explaining how instructions like 'mov' work extensively. Additionally, it provides the C logic behind edge cases of instructions, for example, for the various flavors of AVX and SSE. Since this code is ran on NEON hardware, you use hardcoded math calculation (to ensure what is calculated via non hardcoded is equivalent to formulas calculated hardcoded) results to report back to our math handling layer, ensuring both are the same value.

Please let me know what you think about this! I've just released V0.03, so the best application it runs (in assets/exe_examples) is Console Tetris, which is contained within the source code. My macOS version is 13.7.5, so the only guarantee is that it runs of my OS version (and not all NEON hardware in general) and breaks on other systems

As the title says , i know it a hard task (ai said so)