asm.fm — a chiptune synthesizer in pure x86-64 assembly (no libc, no audio lib)
▲ 148 r/programmation+9 crossposts

asm.fm — a chiptune synthesizer in pure x86-64 assembly (no libc, no audio lib)

Learning project that became my favourite: a chiptune synth written entirely in x86-64 assembly (Linux, NASM). No libc, no audio library — just computing raw 16-bit samples and writing a WAV header by hand.

The premise is that sound is just a list of numbers (44100/second) describing where a speaker sits. So the whole synth is: generate the numbers, write them out.

It does four oscillators (square/saw/triangle + LFSR noise), polyphony by mixing voices into one buffer, ADSR envelopes, and FM synthesis with a hand-built sine table. Working on effects next (vibrato, delay, reverb).

github.com/whispem/asm.fm

Feedback on the low-level details welcome — especially the fixed-point math in the FM operator.

u/whispem — 3 days ago
▲ 5 r/Assembly_language+1 crossposts

A 13 KB TCP key/value store speaking raw syscalls — epoll, accept4, mmap arena, no libc (x86-64 NASM)

Single-node key/value store, line protocol over TCP, pure NASM on Linux — syscall or nothing.

The syscall-level bits worth a look:

**•**	epoll event loop with accept4(SOCK\_NONBLOCK): clients are born non-blocking, no fcntl dance  
**•**	replies via sendto + MSG\_NOSIGNAL: SIGPIPE never happens, no signal handler needed  
**•**	close() is the entire connection teardown — epoll tracks the file description, so the fd deregisters itself  
**•**	per-connection state indexed straight by fd: O(1), free  
**•**	FNV-1a, open addressing, tombstone reuse; 256 MB mmap bump arena behind it  
**•**	200 concurrent clients at 1.4 MB RSS; Docker image is FROM scratch plus one file

Known limits documented in the README — biggest one: slow readers are dropped, EPOLLOUT write buffering is next.

Feedback welcome, especially on the event-loop structure.

github.com
u/whispem — 24 days ago

From a literature degree to an AUC 0.996 classifier: what my data science capstone taught me about learning ML

My path into ML was not standard: a literature-track high school diploma, a degree in Italian, jobs as a librarian and in school administration.
In 2024 I was taking a course on basic computer skills.
This year I finished a university data science diploma (Aix-Marseille School of Economics).

My capstone was a breast tumor classification pipeline (malignant vs benign) in Python with scikit-learn, and it taught me more than any tutorial.
The headline result: a model using only 5 features matched the full 30-feature model (AUC 0.996) — and those 5 features align with the criteria pathologists actually use in practice.

What that project drilled into me, and what I’d tell other beginners:

1.	EDA first, always. Understand the data before touching a model. (I got so obsessed with fast exploratory analysis that I ended up building my own terminal tool for it, dprism.)  
2.	Simple baselines before anything fancy. The boring model is your reference point.  
3.	Fewer features can be a feature. Parsimony isn’t a compromise — a 5-variable model you can explain beats a black box with the same AUC.  
4.	Interpretability builds trust. The moment the model’s chosen features matched domain experts’ criteria, the whole thing became credible.

If you’re coming to ML from a non-STEM background and wondering if you belong here: you do.
Happy to answer questions about the project or the path.

Code: https://github.com/whispem/breast-cancer-diagnosis

github.com
u/whispem — 26 days ago

My language’s compiler now compiles itself with byte-identical output (SHA-1 fixed point) — self-hosted in ~1,700 lines, running on a standalone C VM

whispem-lang is a small language I’ve been building to understand how languages actually work — Rust was my first programming language two years ago, and this project is where the "how does a compiler even work" itch led me.

Where it stands now:

•	Self-hosted compiler: the full pipeline (wsc.wsp, \~1,700 lines) is written in Whispem itself. Source in, bytecode out.  
•	Verified bootstrap: the compiler compiles itself, and both outputs (self-hosted vs the reference Rust implementation) share the same SHA-1 — a stable fixed point.  
•	Runtime: a standalone single-file C VM (\~2,000 lines) with an interactive REPL and a --dump disassembler. No dependencies beyond a C compiler.  
•	Tests: 200+ across the Rust and C sides, including bootstrap verification.

Question for this sub: where would you go next? Optimization passes on the bytecode?
Self-hosting the VM too?
Better error recovery in the parser?
Curious what people who’ve done this longer than me consider the highest-value next step.

Repo: https://github.com/whispem/whispem-lang

github.com
u/whispem — 26 days ago

In 2024 I was taking a "basic computer skills" course. This year my programming language’s compiler compiled itself. Notes from an unusual path.

I come from the least technical background imaginable: a literature-track high school diploma, a degree in Italian, and a string of jobs that had nothing to do with code — librarian, sales assistant in a department store, school administration.
In 2024, I enrolled in a course teaching fundamental computer skills.
Not programming. Files and folders.

Then I started coding, and against all advice I picked Rust as my first language.
Everyone says it’s a terrible first language.
For me it worked: the compiler is strict, but it’s the most patient teacher I’ve ever had.
It tells you exactly what’s wrong and never gets tired of repeating it.

Since then, I’ve learned by building:
• x86-64 assembly from scratch (printf, malloc, a small shell — syscalls only) to understand what’s under the floor
• a distributed key-value store in Rust (Raft consensus, transactions, write-ahead log) that somehow has 300+ stars now
• an ML project for my data science diploma (breast tumor classification)
• and the one I’m proudest of: a small programming language whose compiler is written in the language itself, and compiles itself with byte-identical output

I just finished a university data science diploma, and I’m writing this in the middle of École 42’s “piscine” (a 4-week intensive selection bootcamp).

What actually helped:
1. Building things I wanted to exist, not tutorial projects
2. Doing everything in public — it forces you to actually understand what you ship
3. Community: I started a local Rust meetup in my city, and explaining things to others is the fastest way to learn them
4. Treating error messages as lessons, not judgments
Not a genius story. Just consistency, curiosity, and an unreasonable number of compiler errors.

Happy to answer anything about starting from zero as an adult, learning Rust first, or building while studying.
Everything I’ve made is open source: https://github.com/whispem

u/whispem — 27 days ago
▲ 106 r/asm+6 crossposts

En pleine piscine 42, j'ai décidé que le C n'était pas assez bas niveau: je réécris l'userland en assembleur

Contexte: piscine 42 en cours.

Comme le C ne suffisait visiblement pas à ma peine, j'ai ouvert un repo pour réapprendre l'userland en x86-64:

Linux, NASM, pas de libc, pas d'appels externes — syscall ou rien.

Déjà fait: cat, wc, ls et grep (classés « échauffement », oui) ; printf from scratch, varargs à la main et parsing du format compris ; malloc sur brk/mmap, avec free lists et alignement ; et un shell qui gère fork, execve, les pipes et les redirections.

La roadmap monte jusqu'au bootloader et au mini-noyau, dans une section honnêtement intitulée « SEEK HELP ».

Le repo est en MIT, écrit pour être lu: https://github.com/whispem/learn-assembly-with-em

Si vous voyez des horreurs dedans (il y en a), dites-le-moi — c'est littéralement le but.

u/whispem — 1 month ago
▲ 2 r/machinetranslation+1 crossposts

sussurro.cpp: I reimplemented the OPUS-MT / Marian translation architecture (encoder–decoder seq2seq) in C++ on ggml

A solo project I just opened up — the core is a C++ translation library built on ggml.

The fun part was reimplementing an encoder–decoder Transformer (the Helsinki-NLP OPUS-MT / Marian architecture) from scratch: cross-attention between encoder and decoder, an incremental KV cache, greedy and beam-search decoding, SentencePiece tokenization, and sentence splitting — packaged as a single sussurro_core library, C++17.

Most ggml ports are decoder-only LLMs or vision/ASR models, so getting a seq2seq MT model running was a different shape of problem.

What it does

Offline neural translation + voice across English, Spanish, French and Italian (all 12 directions), with speech-to-text (whisper.cpp) and text-to-speech (Piper via sherpa-onnx) wired in. Everything runs locally.

Some details C++ folks might care about

  • f16 / q8_0 / q4_0 weights; each model is a single self-contained gguf (weights + hyper-parameters + tokenizers)
  • incremental KV cache, so the decoder context isn't recomputed each step
  • runs on Apple Silicon via ggml's Metal backend; a short sentence is ~25 ms on an M5 Max
  • dependencies are ggml, whisper.cpp, sherpa-onnx, SentencePiece and miniaudio — no Python at runtime

MIT.

Happy to discuss the implementation.

github.com
u/whispem — 2 months ago