ABOUT THE WORK

DEADBYTE / DBYTE

I build DBYTE because I like systems I can still fit in my head. Compiler, runtime, VM, native backend and object writers live close together so I can chase a bad result from source text down to the bytes instead of blaming a black box.

What is alive right now?

13.5.0 is the latest locally sealed software release for Windows x64 and GNU/Linux x86-64. It adds bounded compile-time loops and pure compile-time functions. The historical 13.2.0 Linux release has the BIOSTAR physical-host qualification; 13.5.0 does not. DByte REAL_STORAGE remains DISARMED and FULL_OS is not claimed.

Current manual · 13.5 offline proof · historical BIOSTAR proof.

Rules from the machine room

One semantic authority. Backends do not invent language behavior.
Raw source, package bytes and release identities outrank polished prose.
Target-specific ABI and hardware facts stay target-specific.
Virtual proof and physical proof are never merged by wording.
Restore to known-good is a feature.
Cut the problem boundary before adding another framework.

Why not hide behind a giant stack?

Libraries are fine when I can see the boundary. DBYTE owns the parts where owning them makes bugs easier to see or the output easier to reproduce. Rewriting the universe for fun would be stupid; the code budget is real.

If the prose and the machine disagree, the prose does not win because it looks nicer.

Write code. Know what it does.

I am sick of software that needs a tower of tools just to print one line. A compiler ought to be something I can open, trace and fix. Source goes in. Instructions come out. If I cannot explain the middle, that is my problem to solve, not something to bury under another abstraction.

I do not want DBYTE to win a buzzword contest. I want the machine to do exactly what I told it to do. Smaller systems, hard evidence, and the freedom to pull the whole thing apart when it breaks. Terry A. Davis reminded me how far one stubborn programmer can take that idea. DBYTE is my own attempt, not a copy of his code.

License: give the code away

For the upcoming 13.6.0 development branch, the original DBYTE code I own is dedicated to the public domain through CC0-1.0. Use it, study it, fork it, sell what you build with it. I am writing this compiler to make things, not to count how many times someone asks me for permission.

Release boundary: 13.6.0 is still a draft, not a download or a sealed release. The currently distributed 13.5.0 and earlier archives keep the license shipped inside each archive; their notices do not change retroactively. Dependencies, outside code and assets still belong to their own authors. See the actual release state.

Domain rant

I want dbytelang.org eventually. .org fits a non-profit hobby systems project better than .site. DBYTE is not a company and I am not trying to turn this into a subscription machine.

Why am I still on .site? I am broke. A second domain still costs money, and right now I would rather keep that money and keep shipping compiler bytes. When the budget stops being a joke, .org can happen. Until then, .site works.

In memory

Terry A. Davis (1969 - 2018). Rest in peace.

Thank you for what you gave us. Your work still reminds us that one person can build and understand a whole system.