docs: split docs

5 files changed, 305 insertions, 16 deletions

diff --git a/docs/README.md b/docs/README.md
new file mode 100644
index 0000000..fe42c75
--- /dev/null
+++ b/docs/README.md
@@ -0,0 +1,17 @@
+# hdass documentation
+
+hdass is a small superset of assembly: you keep registers, memory and explicit
+control flow, and write the repetitive parts (moves, arithmetic, loops, branches)
+more compactly. It transpiles to x86-64 (NASM or fasm) or AArch64 (GNU as).
+
+- [Getting started](getting-started.md) — build the compiler, then write and run
+  a first program on both x86-64 and AArch64.
+- [Language reference](language.md) — the full syntax: declarations, statements,
+  control flow, memory, floating point, raw instructions and extensions.
+- [Targets](targets.md) — the architecture and assembler axes, what each target
+  supports, the portable register model, and the per-architecture syscall ABIs.
+- [Internals](internals.md) — the `lex → parse → analyze → emit` pipeline and how
+  to add a new assembler backend or architecture.
+
+Working programs live in [examples/](../examples/) (x86-64) and
+[examples/arm64/](../examples/arm64/).
diff --git a/docs/getting-started.md b/docs/getting-started.md
new file mode 100644
index 0000000..6f90618
--- /dev/null
+++ b/docs/getting-started.md
@@ -0,0 +1,107 @@
+# Getting started
+
+## Build the compiler
+
+hdass builds with [Meson](https://mesonbuild.com/):
+
+```bash
+meson setup build
+meson compile -C build
+```
+
+That produces `build/hdass`. It has two options you need: `-o <file>` writes the
+output (default stdout), and `-t <target>` picks the assembler and architecture
+(`nasm` by default, `fasm`, or `arm64`). `build/hdass --help` lists the rest.
+
+hdass only *transpiles*: it emits assembly text, which you assemble and link
+yourself. The examples target Linux, so you need an x86-64 (and
+for AArch64, an aarch64) Linux toolchain. The bundled
+[Docker image](../README.md#building) has `nasm`, `fasm`, an aarch64
+cross-assembler and `qemu`; the commands below run inside it:
+
+```bash
+docker compose up -d
+docker compose exec hdass bash
+```
+
+## A first program (x86-64)
+
+Put this in `hello.hdass`:
+
+```hdass
+[entry: main]
+
+const SYS_WRITE = 1
+const SYS_EXIT = 60
+const STDOUT = 1
+
+data message = "Hello, hdass!\n"
+
+proc main
+{
+    rax = SYS_WRITE     // write(STDOUT, message, message.len)
+    rdi = STDOUT
+    rsi = message
+    rdx = message.len
+    syscall
+
+    rax = SYS_EXIT      // exit(0)
+    rdi = 0
+    syscall
+}
+```
+
+Transpile, assemble, link and run:
+
+```bash
+./build/hdass hello.hdass -o hello.asm
+nasm -f elf64 hello.asm -o hello.o
+ld -e main hello.o -o hello
+./hello
+```
+
+It prints `Hello, hdass!`. `[entry: main]` exports `main` and drops its `ret`, so
+the procedure ends the program itself with the exit syscall; `ld -e main` uses it
+as the start symbol. Swap `-t fasm` and `fasm hello.asm hello.o` to use fasm
+instead — the machine code is the same.
+
+## Running on AArch64
+
+The same source model runs on ARM, but the syscall ABI differs (numbers and
+argument registers), so this program is AArch64-specific. Written with the
+[`logical_registers`](targets.md#the-portable-register-model) extension so the
+registers read the same on both architectures:
+
+```hdass
+[entry: main]
+[enable: logical_registers]
+
+const SYS_EXIT = 93     // AArch64 Linux exit
+
+proc main
+{
+    r1 = 42             // x0 = exit code
+    r9 = SYS_EXIT       // x8 = syscall number
+    syscall             // svc #0
+}
+```
+
+Build it for AArch64 and run it under qemu:
+
+```bash
+./build/hdass -t arm64 exit.hdass -o exit.s
+aarch64-linux-gnu-as exit.s -o exit.o
+aarch64-linux-gnu-ld -e main exit.o -o exit
+qemu-aarch64 ./exit          # exits 42
+```
+
+`r1` maps to `x0` and `r9` to `x8`, `syscall` becomes `svc #0`. See
+[Targets](targets.md) for the register mapping and the ABI tables.
+
+## Next
+
+- The whole language: [language reference](language.md).
+- What runs where and why programs still carry per-architecture ABI details:
+  [targets](targets.md).
+- More programs to read: [examples/](../examples/) and
+  [examples/arm64/](../examples/arm64/), each runnable with the steps above.
diff --git a/docs/internals.md b/docs/internals.md
new file mode 100644
index 0000000..b8c81ba
--- /dev/null
+++ b/docs/internals.md
@@ -0,0 +1,76 @@
+# Internals
+
+hdass is a straight pipeline: `lex → parse → analyze → emit`. Each stage is one
+pair of files under [`src/`](../src).
+
+| Stage | Files | Does |
+| --- | --- | --- |
+| CLI | `main.c`, `args.c` | parse arguments, pick a target, drive the pipeline |
+| Lex | `lexer.c` | source text → a stream of tokens |
+| Parse | `parser.c`, `ast.c` | tokens → an AST (`struct Program` of procs and declarations) |
+| Analyze | `sema.c` | check the AST: undefined names, entry point, constant/reference rules |
+| Emit | `codegen.c` | AST → assembly text for the chosen target |
+| Support | `diag.c`, `file.c` | caret diagnostics, file reading |
+
+The AST is mostly architecture-neutral (assignments, control flow, `^` memory,
+calls, a raw instruction), so almost all of hdass is shared. The architecture
+lives entirely in code generation.
+
+## Two seams in codegen
+
+Code generation is split along the same two axes as a [target](targets.md):
+
+- **`struct Arch`** — instruction selection. One hook, `emit_proc`, turns a
+  procedure's statements into that architecture's instructions (its register
+  model, mnemonics, stack frames). `x86_arch` and `aarch64_arch` implement it.
+- **`struct Backend`** — assembler syntax. Framing hooks (`prologue`, `constant`,
+  `data_section`, `string_data`, `float_slot`, `text_section`, `global`,
+  `boot_signature`) write the file structure around the instructions.
+  `nasm_backend`, `fasm_backend` and `gas_backend` implement it.
+
+`generate(program, out, arch, backend)` orchestrates the two. A public entry
+point is just a pairing:
+
+```c
+void generate_nasm(struct Program* program, FILE* out)
+{
+    generate(program, out, &x86_arch, &nasm_backend);
+}
+```
+
+So `nasm` and `fasm` reuse one x86 instruction selector with different framing,
+and `arm64` pairs its own selector with GNU as.
+
+## Adding an assembler backend
+
+To emit a new *syntax* for an existing architecture (say masm for x86-64):
+
+1. Write the framing functions (`masm_prologue`, `masm_constant`, …) and gather
+   them into a `static const struct Backend masm_backend`.
+2. Add `generate_masm` that pairs `x86_arch` with it.
+3. Wire a `-t masm` name in `args.c` and dispatch to it in `main.c`.
+
+Only the framing differs; the instruction bodies come from `x86_arch` unchanged.
+
+## Adding an architecture
+
+To emit a new *instruction set* (the larger job):
+
+1. Write an `emit_proc_<arch>` and the helpers it needs — a register mapping, an
+   operand renderer, and lowerings for each statement kind. The AArch64 selector
+   is the template: it maps logical `rN → x(N-1)`, renders `#immediate` operands,
+   and lowers assignment/arithmetic/branch/call/syscall.
+2. Gather it into a `static const struct Arch <arch>_arch`.
+3. Pick an assembler `Backend` (GNU as suits most non-x86 targets — reuse
+   `gas_backend` or write one), add `generate_<arch>`, and wire a `-t` name.
+
+Unsupported statement kinds should emit a `; TODO` comment instead of incorrect
+instructions, the convention the existing selectors already use for gaps.
+
+## Building and checking
+
+Meson drives the build; see [getting started](getting-started.md). The test suite
+(`build/tests`) covers the lexer, parser, sema and codegen for every target. If
+`cppcheck` is installed, `ninja -C build cppcheck` runs static analysis. The
+scripts under [`scripts/`](../scripts) assemble and run every example end to end
+in Docker.
diff --git a/docs/language.md b/docs/language.md
index ecdbf19..96f534b 100644
--- a/docs/language.md
+++ b/docs/language.md
@@ -1,16 +1,8 @@
 # hdass language reference
 
-hdass has two independent axes: the **architecture** (which instructions and registers) and the **assembler syntax** (how they are written). A target is a pairing:
+This is the language reference. hdass transpiles to x86-64 (NASM or fasm, `-t nasm`/`-t fasm`) and AArch64 (`-t arm64`); for which target supports what, the portable [`logical_registers`](#logical_registers) model, and the per-architecture syscall ABIs, see [Targets](targets.md). New here? Start with [Getting started](getting-started.md). Pipeline: `lex → parse → analyze → emit`.
 
-| `-t` | architecture | assembler |
-| --- | --- | --- |
-| `nasm` (default) | x86-64 | NASM |
-| `fasm` | x86-64 | fasm |
-| `arm64` | AArch64 | GNU as |
-
-For x86-64 the two syntaxes emit the same Intel instruction bodies and differ only in framing (headers, sections, constants, data). `arm64` is a separate instruction selector — different registers, three-operand arithmetic, `ldr`/`str`, `cmp`+`b.cond`, `svc #0` — and is early: assignments, arithmetic (`+ - * /`), control flow, calls, `syscall`, and the raw instruction statement work; floats, stack buffers, and division-remainder do not yet. masm is planned. Pipeline: `lex → parse → analyze → emit`.
-
-The portable way to write for more than one architecture is the [`logical_registers`](#extensions) extension: `r1..r14` are the general-purpose registers, mapped per target (x86-64 `r1 = rax`; AArch64 `r1 = x0`, i.e. `rN → x(N-1)`). Architecture-native register names (`rax`, `x0`) and the raw instruction statement are, by definition, locked to one architecture. Syscall ABIs also differ per architecture — Linux exit is `60` in `rax` on x86-64 but `93` in `x8` (logical `r9`) on AArch64 — so programs still carry arch-specific ABI constants even when the language is portable. The output isn't tied to an OS, but the examples and toolchain here target Linux (ELF, `ld` / `qemu-aarch64`).
+The examples below use x86-64 register names. The output isn't tied to an OS, but the examples and toolchain here target Linux (ELF, `ld`).
 
 ## A first program
 
@@ -48,15 +40,21 @@ rax = 1        // line
 
 ## Directives
 
-Top-level `[key: value]`, configuring the whole program.
+Top-level `[key: value]` (or bare `[key]`), configuring the whole program.
 
 | Directive | Meaning |
 | --- | --- |
-| `[bits: 64]` / `[bits: 32]` | Target bitness. Default 64. |
+| `[bits: 64]` / `[bits: 32]` / `[bits: 16]` | Target bitness. Default 64. |
 | `[entry: NAME]` | Makes procedure `NAME` the entry point. |
 | `[enable: NAME]` | Turns on an [extension](#extensions). |
+| `[format: bin]` / `[format: elf]` | Output a flat binary instead of an ELF object. Default elf. |
+| `[org: 0x7C00]` | Set the load address of a flat binary. |
+| `[boot]` | Pad a flat binary to 510 bytes and append the `0xAA55` boot signature. |
 
-Unknown keys, a `bits` value other than 32/64, and unknown extensions are errors.
+The last three build a raw binary instead of a linked ELF, enough for an x86
+boot sector. In `bin` format there are no sections or exported symbols, and code
+comes first so execution starts at the origin. Unknown keys, a bad `bits` value,
+and unknown extensions are errors.
 
 ## Constants and data
 
@@ -117,7 +115,7 @@ Each procedure ends with `ret`, except the entry point. `[entry: NAME]` exports
 
 ## Registers
 
-Written by their architecture names — `rax`–`rdi`, `rbp`, `rsp`, `r8`–`r15` — and their sub-registers (`al`, `ax`, `eax`, `dl`, …), which imply a store's size. The [`logical_registers`](#extensions) extension adds `r1`–`r14`.
+Written by their architecture names — `rax`–`rdi`, `rbp`, `rsp`, `r8`–`r15` — and their sub-registers (`al`, `ax`, `eax`, `dl`, …), which imply a store's size. The [`logical_registers`](#logical_registers) extension adds `r1`–`r14`. The segment registers (`cs ds es fs gs ss`) and control registers (`cr0 cr2 cr3 cr4`) are also recognised, for systems code that sets up segments or switches CPU modes.
 
 ## Statements
 
@@ -214,6 +212,21 @@ rbx = ^signed word rsi     // movsx rbx, word [rsi]
 rcx = ^signed dword rsi    // movsxd rcx, dword [rsi]
 ```
 
+## Raw instructions
+
+Any statement that isn't an assignment, label, call or keyword is emitted as a bare instruction: a mnemonic and its operands, written in hdass's own operand syntax. This is the escape hatch for everything outside the assignment and control-flow model: `int`, `hlt`, `cli`/`sti`, `lgdt`, port I/O, the mode switch. Operands are the usual registers, immediates, constants and `^memory`, and share the mnemonic's line.
+
+```hdass
+cli
+int 0x10
+out 0x64, al
+lgdt ^gdt           // lgdt [gdt]
+cr0 = eax           // an ordinary move; segment/control regs work with `=` too
+hlt
+```
+
+Mnemonics pass straight through, so a typo is reported by the assembler. Operands render through the same path as everywhere else, so an instruction is as portable as the rest of the language, though the mnemonics themselves are architecture-specific.
+
 ## Expressions
 
 Assignment values and `if` operands: registers, integers, chars (`'0'`), constants, data names, member access (`data.len`), and `+` `-` `*` `/` `%`. Operators are left-associative and each right-hand operand must be a single term, so `a * b + c` works but `a + b * c` (a nested right operand) doesn't yet.
@@ -299,8 +312,7 @@ fasm program.asm program.o
 ld -e main program.o -o program
 ```
 
-The [README](../README.md) has a Docker setup with these tools.
+For `-t arm64` and the full toolchain (including the AArch64 cross-assembler and qemu), see [Getting started](getting-started.md); the [README](../README.md) has the Docker setup.
 
 ## Some stinkies
 Clobbering is your responsibility: `syscall` trashes `rcx` and `r11`, while a callee can trash any registers it touches, so nothing is saved automatically. `examples/fibonacci.hdass`, for example, keeps its counter in `r15` for this reason. Register widths must also match, meaning something like `rax = r1.8` would become `mov rax, al`, which will not assemble. Division clobbers extra registers: `/` `%` and their `=` forms use `idiv` through `rax:rdx`, so both are overwritten regardless of the destination. The divisor can be anything — a register, a constant, or an immediate — but an immediate or an `rax`/`rdx` divisor is first copied into `r11`, so those also clobber `r11`. Labels and procedures become plain assembler symbols, so avoid names the target assembler reserves: `loop`, for instance, is an instruction mnemonic that fasm rejects as a label (nasm allows it). Finally, the entry procedure has no `ret`; it should end with an exit syscall.
-
diff --git a/docs/targets.md b/docs/targets.md
new file mode 100644
index 0000000..c54636b
--- /dev/null
+++ b/docs/targets.md
@@ -0,0 +1,77 @@
+# Targets
+
+hdass separates two things that assemblers usually tangle together:
+
+- the **architecture** — which instructions exist and how registers work;
+- the **assembler syntax** — how those instructions are written to a file.
+
+A target is a pairing of the two, chosen with `-t`:
+
+| `-t` | architecture | assembler | notes |
+| --- | --- | --- | --- |
+| `nasm` (default) | x86-64 | NASM | Intel syntax, `nasm -f elf64` |
+| `fasm` | x86-64 | fasm | Intel syntax, `fasm` (one step) |
+| `arm64` | AArch64 | GNU as | `aarch64-linux-gnu-as` |
+
+For x86-64, `nasm` and `fasm` emit the **same instruction bodies** and differ only
+in framing (file header, sections, constant and data syntax). `arm64` is a
+separate instruction selector: different registers, three-operand arithmetic,
+`ldr`/`str` memory, `cmp`+`b.cond` branches and `svc #0` syscalls.
+
+`masm` (x86-64) and a 32-bit `arm` target are planned.
+
+## What each architecture supports
+
+The language is the same; not every construct lowers on every architecture yet.
+
+| Feature | x86-64 | AArch64 |
+| --- | --- | --- |
+| Moves, arithmetic (`+ - * /`), compound assignment | ✅ | ✅ |
+| `if` / `else` / `while`, `goto`, labels | ✅ | ✅ |
+| Conditional select (`a if c else b`) | ✅ `cmov` | ✅ `csel` |
+| Calls, `syscall` | ✅ | ✅ |
+| Memory load/store (`^`), sized and signed | ✅ | partial (`ldr`/`str`) |
+| Raw instruction statement | ✅ | ✅ |
+| Modulo (`%`), division remainder | ✅ | ❌ not yet |
+| Floating point (`xmm`) | ✅ | ❌ not yet |
+| `stack` buffers | ✅ | ❌ not yet |
+| Bare-metal directives (`format`, `org`, `boot`, `bits 16`) | ✅ | — (x86/BIOS concept) |
+
+Unsupported constructs emit a `; TODO` comment instead of incorrect instructions.
+
+## The portable register model
+
+Architecture-native register names (`rax` on x86-64, `x0` on AArch64) lock a
+program to one architecture. To write for both, enable
+[`logical_registers`](language.md#logical_registers): `r1`–`r14` are the
+general-purpose registers, mapped per target.
+
+| logical | `r1` | `r2` | `r3` | `r4` | `r5` | `r6` | `r7` | `r8` | `r9` | `r10` | … |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| x86-64 | rax | rbx | rcx | rdx | rsi | rdi | r8 | r9 | r10 | r11 | … |
+| AArch64 | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | … |
+
+AArch64 is simply `rN → x(N-1)`. The raw [instruction statement](language.md#raw-instructions)
+is architecture-locked too: its mnemonics are whatever you write.
+
+## Syscall ABIs differ
+
+Even with logical registers, a *syscall* is not portable: Linux uses different
+call numbers, argument registers and trap instructions per architecture. So a
+program still carries architecture-specific ABI constants.
+
+| | x86-64 | AArch64 |
+| --- | --- | --- |
+| syscall number in | `rax` (logical `r1`) | `x8` (logical `r9`) |
+| arguments in | `rdi rsi rdx r10 r8 r9` | `x0 x1 x2 x3 x4 x5` |
+| trap (`syscall`) | `syscall` | `svc #0` |
+| `exit` number | `60` | `93` |
+| `write` number | `1` | `64` |
+
+C works the same way: portable source, per-platform syscalls.
+
+## OS independence
+
+The emitted instructions aren't tied to an OS; only the syscall numbers and the
+`[entry]`/link convention are. The examples and toolchain here target Linux (ELF,
+`ld`, and `qemu-aarch64` for ARM); see [getting started](getting-started.md).