Releasing Ostomachion v1.0.0, an open-source FPGA platform I have been developing. It integrates a soft RISC-V core, a real-time operating system, and a signal-processing accelerator so that each layer is a thin, well-defined interface over the one below. It runs on an Artix-7 (Opal Kelly XEM7310):

- A NEORV32 RISC-V soft core running the Zephyr RTOS, bare-metal on the fabric.

- A streaming frequency-domain datapath in hardware: a 4096-point FFT, a per-bin programmable complex filter (a coefficient mask H[k] in block RAM), and an inverse FFT — staged through AXI DMA and BRAM, with interrupt aggregation onto the core.

- A header-only C++20 hardware abstraction layer that presents the accelerator to software as ordinary typed calls, so the path from a std::span in a unit test down to a beat on an AXI-Stream bus is a sequence of deliberate, inspectable wrappers.

The whole Vivado block design regenerates from a version-controlled Tcl script — no saved checkpoints, no hand-edited GUI state. Every bitstream derives from text alone, which makes the hardware auditable and diffable in the same way as the software.

The name is Archimedes' Ostomachion, a dissection puzzle of fourteen pieces; the platform is likewise fourteen composable layers, each replaceable in isolation.

A companion desktop application drives the full filter datapath on live hardware over USB: it streams frames to the fabric, programs the filter mask in real time, and plots the input, the mask H[k], and the filtered output as the transform runs — the genuine hardware pipeline end to end, not a software model of it.

Source, documentation, and design rationale (GPL-3.0; commercial licensing available):

github.com/andynicholson/Ostomachion

Basic project to learn more about Linux system calls and C programming. I accept any criticism.

Hi there.

I built polloc (pool alloc) to learn how memory allocators work.

It’s a fixed size pool allocator: each pool manages one slot size and alignment. Internally it uses mmap/VirtualAlloc, an intrusive free list, and a bitmap for allocation tracking.

I also added stress tests, Miri, AddressSanitizer, cargo fuzz, Criterion benchmarks, and a bunch of inline docs explaining the implementation.

For 64 byte alloc/free pairs, the fast path is about ~3.96x faster than the system allocator on my machine (which is expected since it’s specialized for a single size class).

It’s single threaded and I’d really appreciate feedback on the unsafe code, API design, tests, or anything else that stands out.

repo: https://github.com/hamzader1/polloc

like what do i do. my target is low latency/systems/hft but i dont know where to begin. and i dont know anything. so any recommendations on where to start, what to learn first, etc.

I would like to share my Linux Syscall Monitor project with you. It's a Linux process monitoring tool written in C that uses "ptrace" to observe system calls and generate behavioral reports.

I welcome any feedback or criticism—whether it's about the code .[repo](https://github.com/tracebyte8/linux-syscall-monitor)

I wanted to actually understand what happens under libc, so I started rebuilding the pieces: printf (varargs by hand, format parsing), malloc (brk/mmap, free lists, alignment), a shell (fork, execve, pipes, redirections), plus cat/wc/ls/grep as warm-up.

Rules of the game: x86-64 Linux, NASM, `syscall` or nothing.

Favorite rabbit hole so far: how much of printf is just careful pointer arithmetic over the SysV varargs ABI — and how little of malloc is actually about allocating (it's bookkeeping all the way down).

Repo (MIT, written to be read): https://github.com/whispem/learn-assembly-with-em

Happy to discuss design choices — and happier to be told where I'm wrong.

SHOFTY es un pequeño sistema operativo que he estado desarrollando desde cero, llamado así por mi gato esmoquin. Arranca desde su propio sector de arranque de 512 bytes a un kernel de 16 bits en modo real; todo está escrito a mano en NASM, sin rastro de C en el proyecto. Características actuales:

El sector de arranque carga el kernel desde el disco mediante la interrupción 0x13 (con conversión de LBA a CHS incluida).

Pantalla de arranque ASCII con el gato, obviamente.

Pantalla de inicio de sesión: introduce un nombre de usuario o pulsa Intro para el usuario invitado.

Menú de arranque con navegación mediante flechas: la interrupción 0x16 escanea los códigos de las flechas, y la interrupción 0x10 (AH=09h) la barra de resaltado estilo BIOS con atributos invertidos. Consola interactiva: entrada de línea con manejo de retroceso, comparación de cadenas para la ejecución de comandos (ayuda / eliminar / cat / disktest). Modo VGA 13h (320x200x256).

Rutinas de lectura/escritura para sectores sin formato: la base de SFM (SYS File Manager), su propio sistema de archivos, que es lo que estoy desarrollando a continuación.

El kernel completo ocupa 8 KB. Ensamblado con nasm -f bin, se ejecuta en QEMU (y, en teoría, debería funcionar en hardware real de hace 40 años).

Soy autodidacta, así que agradezco cualquier comentario honesto sobre el código ensamblador. Si algo en el código te parece extraño, por favor, házmelo saber. Repositorio: github.com/metaspawn

GPL-3.0, parte de mis proyectos MetaSpawn. Sin fines comerciales; lo desarrollo para aprender y compartir.

Started this because I wanted ncu's device__attribute_* values without handing it a kernel to profile. It grew into a small zero-dependency toolkit (pip install kernelmeter):

- `info` dumps every cuDeviceGetAttribute value straight from libcuda (no toolkit needed), plus NVML facts and derived theoretical peaks

- `bench` times kernels with CUDA events (L2 flushed between iters), checks correctness against a reference, and scores against the roofline: you get "76% of attainable for this arithmetic intensity" instead of a bare ms number. It also samples clocks/power during the run and rescores against the sustained-clock ceiling. My favorite result: cuBLAS fp32 matmul on a 70W T4 showed 52.7% of peak, looked like a kernel problem, but the telemetry showed the card pinned at its power limit at 877MHz, where the kernel was actually at 95.5%. cuBLAS was never the problem.

- `occupancy --block 256 --regs 64 --smem 8192 --cc 8.6` reimplements the old calculator: names the limiting resource and sweeps block sizes. Works with no GPU present.

- `ceiling` measures real achievable bandwidth (STREAM) and fp32 (TF32-disabled matmul), because theoretical peaks are never reachable and it's worth knowing your honest 100%.

- `compare`/`llm` do the same roofline math across a 40-card database (NVIDIA and AMD) for rent/buy decisions, no GPU needed.

Every number in the README is captured output from real runs (T4, MI300X). All spec-sheet claims are asserted in CI. MIT.

For now 2 years i try learning how to create an operating from scratch at only 15, now i'm 17 and i've progress in this domain so i publish it, you can look for it on github OScour, the name is a french reference to "au secours" (help), an the prononciation is OScour.

hey everyone! I recently built a slim implementation of how containers work on linux using syscalls and vfs with rust.

Right now its a program that can spawn multiple containers (with busybox rootfs image)and exit gracefully.

I also wrote a blog on how it works underneath, how one could implement it themselvves and some benchmark/profiling as well.

blog: https://op3kay.dev/writing/b0nker

code: https://github.com/owlpharoah/b0nkers

if it looks cool a star would be awesome

Would be nice if I could get some feedback on the blog or code, anything I should include or improve ?

Modern compilers perform extensive semantic analysis:

• type visibility
• symbol visibility
• scope visibility
• object lifetime

But heterogeneous execution is largely invisible to the compiler's semantic model.

Crossing from CPU to GPU usually means crossing into a different compilation model.

Should execution domains become part of semantic analysis rather than remaining a backend concern?

This was my first high-effort low-level project, and it might be of interest to anyone who's interested in compression, SIMD, and branchless programming.

Hey security researchers! 🔐

I've released BareMetal-RAM-Dumper — a low-level x86 utility for dumping 
physical RAM directly to disk, designed for Cold Boot Attack research.

🎯 What it does:
• Custom 512-byte bootloader (no OS needed)
• Boots via BIOS Legacy CSM
• Switches to Unreal Mode to access 32-bit physical memory
• Dumps RAM in 32KB chunks directly to USB drive
• BIOS INT 0x15 E820 for safe memory map parsing
• Real-time progress indicator

🧊 Cold Boot Attack Use Case:
Freeze a laptop's RAM to -60°C → quickly reboot from USB → 
capture full memory contents for forensic analysis & crypto key recovery

🔧 How it works:
1. Stage1: 512-byte boot sector (loads Stage2 via INT 0x13)
2. Stage2: Main logic (memory detection, unreal mode, disk writes)
3. Writes to LBA 64+ on boot drive

⚠️ Warning: This overwrites data starting at sector 64! Use a dedicated blank USB.

📚 Built with pure Assembly (NASM) — no bloat, direct hardware access

GitHub: https://github.com/pIat0n/BareMetal-RAM-Dumper
License: AGPL-3.0

Perfect for:
✅ Forensic researchers
✅ Security auditors testing cold boot resilience
✅ Students learning low-level x86
✅ Penetration testers

Feedback & improvements welcome!

Hey guys, I'm not too good at C++ yet, but I'm trying my best to build RapSocket — a custom, no-std wrapper for WinHTTP. I'm doing this to learn low-level memory management and native Windows networking. I will post my progress here, but if you want to check out the code, here is my Github!

I will be posting daily here: https://r-tty.blogspot.com

From the first attempts to run bios_emulator, to the complete native RISC-V 64-bit VideoBIOS.

In languages like Java or C#, super is a common mechanism for accessing parent class behavior. C++ handles similar cases through explicit base class qualification such as:

Base::method();

All of these mechanisms assume that objects and methods exist in the same execution space.

However, heterogeneous computing breaks this assumption. When a CPU object needs to call a GPU device method inherited from a parent class, the problem is no longer just syntax. It becomes a problem of mapping object relationships across different address spaces and execution models.

I’m working on AET, a GCC-based heterogeneous compiler, and exploring this direction with a new super$ mechanism.

For example:

__global__ void compute(float x)
{
    float r = super$->leaky(x);
}

The compiler analyzes the inheritance relationship, extracts the device function into the GPU compilation path, generates device function mapping tables, and connects the CPU-side object with the GPU-side function address during initialization.

The goal is not to add a heavy runtime object system, but to explore whether high-level object-oriented abstractions can naturally work in heterogeneous programming while still mapping efficiently to hardware.

I’m interested in feedback from compiler/GPU developers: should heterogeneous programming remain explicit like CUDA, or can compilers provide higher-level object abstractions without losing control?