🚀 Blaise v0.12.0 — native by default, zero external tools, and a real standard library

[graemeg]

This is a big one.

As of v0.12.0 the native x86-64 backend is the default,
and Blaise now ships its own internal assembler and internal linker — so a
plain build needs no external tools at all:

// blaise --source hello.pas --output hello
program hello;
begin
  WriteLn('Hello, Blaise 0.12!')
end.

That single command parses, generates native code, assembles it, and links a
working executable — no qbe, no as, no gcc (only the system C runtime
objects the linker needs). QBE is still there if you want it (--backend qbe),
but it is now opt-in and on a path to retirement.

⚙️ Incremental by default

Compilation is now incremental, per unit — each unit becomes its own object
file and the internal linker joins them, just like Free Pascal. Rebuilds are
faster, and the old whole-program path is one flag away (--no-incremental) if
you ever want it. A lot of careful work went into making warm-cache rebuilds
lossless — and the test suite now has a dedicated warm-cache fixpoint guard
so that stays true.

🐛 First-class debugging across units

If you have used the OPDF debugger (pdr), here is the headline: it now works
through every unit of an incrementally-built program, not just the main
file. Set a breakpoint inside a dependency unit, walk a cross-unit callstack,
inspect parameters, locals, and object fields — all of it. Each object file
carries its own debug section and the linker merges them, mirroring how FPC
lays out multi-unit debug info, so pdr reads it without any changes.

📚 A standard library worth the name

v0.12.0 turns the stdlib from a handful of helpers into something you can build
real programs on — all opt-in via uses:

uses Json.Types, Json.Writer;
var o: TJSONObject;
begin
  o := TJSONObject.Create();
  o.Add('name', 'Blaise');
  o.Add('version', 12);
  WriteLn(o.AsJSON());   // {"name":"Blaise","version":12}
  o.Free()
end.

uses Encoding.Base64, Security.Crypto;
begin
  WriteLn(Base64Encode('Blaise'));   // QmxhaXNl
  WriteLn(Sha1Hex('abc'))            // a9993e36...
end.

What landed this cycle:

• JSON — a full DOM, parser, reader, and writer. 🧩
• Encoding.Base64 and Security.Crypto (SHA-1). 🔐
• Security.Guid — RFC 4122 v4 GUIDs.
• Networking — Net.Sockets (IPv4 TCP), Net.WebSockets (RFC 6455), and
  a minimal Net.Http.Server with WebSocket upgrade. 🌐
• Exact numbers — TDecimal (precise decimal arithmetic) and TMoney
  (currency-aware, configurable rounding) — no binary-float surprises. 💷
• StrUtils gained SplitChar, SplitLines, JoinList, and a UTF-8
  CodePointToString.
• The blaise.testing unit-test framework now lives in the stdlib where it
  belongs, with its own test suite.

🗂️ Showcase: Luhmann, a Zettelkasten built in Blaise

The best way to judge a standard library is to build something real on it — so
I did. Luhmann (also released today)
turns a directory of AsciiDoc notes into a personal
Zettelkasten: a local-first web
app that renders your notes, computes backlinks, draws an interactive note
graph, indexes everything for full-text search, and live-reloads your browser
as you edit. It started life as a Clojure/Java program and was reimplemented in
Blaise — and the port gained features along the way (automatic backlinks,
tags, the graph, a broken-links report, a JSON API).

It leans directly on what v0.12.0 shipped:

• Net.Http.Server + Net.Sockets serve the site and the REST API.
• Net.WebSockets drives the live-reload channel — save a note, the browser
  refreshes itself.
• Json.Writer builds the /api/backlinks, /api/graph and /api/tags
  responses.
• Generics.Collections underpins the in-memory link graph and tag index.

It is also a genuine application, not a demo: a framework-free hexagonal
(ports-and-adapters) core with swappable adapters, built with PasBuild. And it
leans on the native backend's concurrency — at start-up it renders notes in
parallel, taking an 86-note corpus from ~13 s serial to ~2 s on 16 cores (6.3×).

That a third-party app of this size compiles, links (zero external tools) and
runs on Blaise is the clearest signal yet that the language and stdlib are ready
for real work. 🙌

✨ Language niceties

A few conservative, FPC/Delphi-friendly additions:

• Qualified type names — SysUtils.TFormatSettings, dotted qualifiers and
  all.
• Chained l-value assignment — Self.FStack[0].Count := value just works.
• Writable string subscript with copy-on-write:

var s: String;
begin
  s := 'hello';
  s[0] := 'H';
  WriteLn(s)          // Hello
end.

• Conditional compilation — {$IFDEF} / {$DEFINE} with a predefined
  BLAISE symbol plus CPU/OS symbols, and -d on the command line.
• Integer-subrange set bases (set of 0..255), named subrange types, and a
  handful of parser corners that used to reject perfectly ordinary code.

🛡️ Hardening

This release also fixed a meaningful batch of native-backend codegen bugs that
varied real-world programs (the new JSON library, especially) flushed out:
floating-point arguments now follow the System V ABI correctly through methods,
constructors, inherited calls and the register-overflow path; implicit-Self
virtual calls dispatch through the vtable; HasClassAttribute works on native;
and several record/interface argument-passing edges were closed. Dogfooding
varied code is the best bug-finder we have. 🔎

✅ Verified

Blaise still bootstraps itself to a byte-for-byte fixpoint — 410,477 lines
of IR, with all four fixpoint guards green (QBE, native, internal-assembler,
and the warm-cache rebuild — the warm-cache guard now also exercises an
edit-then-rebuild). 3,745 compiler tests and 57 stdlib tests pass, and
the whole test suite compiles under Blaise itself.

Grab the v0.12.0 binary from the
GitHub release page — it is a
self-contained native compiler that needs nothing but a C runtime to link
against. See changelog-v0.12.0.md for the full technical detail. And as a bonus,
I've also included a pre-built pdr debugger binary as part of the release archive.

Onwards to v0.13.0! 🙌

Built with ❤ for the Pascal community.

[rchastain2]

Congratulations Graeme. Very impressive work! Can't wait to test the new version of the compiler.

Is there a reason for QBE imminent retirement? I used to like that feature.

[graemeg]

Thanks. From the start QBE was always meant to be temporary and meant to be replaced by the more complex and optimised LLVM. No native backend was planned. Plans however changed, and to get better debugging support, the Native backend was key. Andrew already implemented the LLVM backend, but that still needs to be reviewed and merged at some point.

If we have both Native and LLVM, I don't really see a need for QBE as well. It just adds extra work to maintain, and has less OPDF debugger support. I'm unclear where LLVM stands with debugging - I think it uses DWARF (thus gdb is required).

The future of Blaise now build on the Native backend. My next phase is cross-compiling to Window, FreeBSD and macOS - all without external tools (if possible - that's the hope). And, all with 1st class debugging support via pdr debugger.

Saying all that, QBE will still be around for 2 or 3 release cycles - maybe more. Just until I'm 110% sure the Native backend is well tested. A lot of experimental Native backend things landed in the 0.12.0 release, so it needs lots of community testing. I obviously tried my best to get it as stable as I could before release.

[Schmitty2005]

Excellent release! I will definitely give this a try when I get some time. Thank you!

What is going to be the preferred way of documenting stdlib and other blaise programs ? External files like FPDoc? Inline Comments? XML doc ?

I did see some source code documentation in the numerics.money.pas unit.

I do think the output will probably be ASCIIDoc generated by a blaise tool😃

[graemeg]

@Schmitty2005 Now that I've reached the stage of starting to build out the stdlib, I have started giving it some more though. I've always favoured external xml docs (like what FPC's fpdoc does) - back when I only use Lazarus IDE. But I've hardly touched Lazarus in 10 years, and felt the pain of documentation not being easily accessible in my editors or IDEs of choice.
Also, over the last 6 years of working with Java code and seeing how well inline documentation works - close to the source, and readable/available no matter what editor or IDE you use. Also, much easier to update at the point when you make code changes. I'm now leaning towards inline documentation.

No final decision has been made yet, but I will make one soon.