feat: fasm backend

1 files changed, 9 insertions, 2 deletions

diff --git a/README.md b/README.md
index c3e942e..299b904 100644
--- a/README.md
+++ b/README.md
@@ -3,7 +3,7 @@ hachem's dumb assembly super-set, pronounced "HD Ass", or "headass"...depends on
 
 The entire point of this project is to provide a middle ground between C and assembly. If we think about why we still write assembly today, it's usually because we need direct control over what the CPU is doing. We want control over the exact instructions being executed, the memory, the stack and everything else that higher-level programming languages normally abstract away. The thing is, not every program written in assembly actually needs that control. Sometimes you want to write something close to the machine without having to manuall deal with every tiny detail yourself. You still want registers, explicit control over memory and a good understanding of what your program is doing, but you don't necessarily need to manually express everything as individual assembly instructions.
 
-This is where this piece of shit comes in. It's not quite high-level enough to be a C-like language, but it's also not low-level enough to be as annoying to write as raw assembly. The goal is to sit somewhere in between, keeping the parts of assembly that make it useful while making the parts that don't need to be painful a little nicer to work with. hdass transpiles into multiple flavours of assembly, such as NASM and MASM, rather than directly producing machine code. The idea is to provide a single language for writing low-level programs while allowing the backend to translate code into the assembler syntax you want to target. You're still ultimately producing assembly, and you're never particularly far away from the code that gets assembled. The goal isn't to hide the machine from you or turn assembly into C. There are already plenty of high-level languages that do that. hdass just fills the gap between the two, where you might want some more convenience whilst writing assembly without taking away the reason you wanted to work close to the machine in the first place.
+This is where this piece of shit comes in. It's not quite high-level enough to be a C-like language, but it's also not low-level enough to be as annoying to write as raw assembly. The goal is to sit somewhere in between, keeping the parts of assembly that make it useful while making the parts that don't need to be painful a little nicer to work with. hdass transpiles into multiple flavours of assembly, currently NASM and FASM (MASM is planned), rather than directly producing machine code. The idea is to provide a single language for writing low-level programs while allowing the backend to translate code into the assembler syntax you want to target. You're still ultimately producing assembly, and you're never particularly far away from the code that gets assembled. The goal isn't to hide the machine from you or turn assembly into C. There are already plenty of high-level languages that do that. hdass just fills the gap between the two, where you might want some more convenience whilst writing assembly without taking away the reason you wanted to work close to the machine in the first place.
 
 ## Examples
 Here's a simple "Hello, World!" world program written using hdass' syntax:
@@ -53,7 +53,7 @@ meson test -C build
 ```
 If [cppcheck](https://cppcheck.sourceforge.io/) is installed, `ninja -C build cppcheck` runs static analysis over the sources.
 
-hdass emits x86-64 assembly, so to actually assemble and run its output you need an x86-64 Linux toolchain. The bundled Docker environment provides a consistent one on any host, including Apple Silicon, where the amd64 image runs under emulation. The image is a Debian base with `nasm`, `ld` (binutils), a C toolchain and Meson/Ninja preinstalled.
+hdass emits x86-64 assembly, so to actually assemble and run its output you need an x86-64 Linux toolchain. The bundled Docker environment provides a consistent one on any host, including Apple Silicon, where the amd64 image runs under emulation. The image is a Debian base with `nasm`, `fasm`, `ld` (binutils), a C toolchain and Meson/Ninja preinstalled.
 
 Start the container (this builds the image the first time):
 ```bash
@@ -74,6 +74,13 @@ ld -e main hello.o -o hello
 ./hello
 ```
 
+hdass targets NASM by default; pass `-t fasm` to emit FASM instead, which assembles in a single step:
+```bash
+./build-linux/hdass -t fasm examples/hello_world.hdass -o hello.asm
+fasm hello.asm hello.o
+ld -e main hello.o -o hello
+```
+
 To transpile, assemble, link and run every program in [examples/](examples/) and check its output, use the end-to-end test script (also from inside the container):
 ```bash
 meson setup build-linux && meson compile -C build-linux && ./scripts/test_examples.sh