Вирт - русифицированный паскаль. A modern, self-hosting Object Pascal compiler built for the 2020s. Zero legacy, full ARC, and unified UTF-8.
Find a file
Andrew Haines a0e0fd567b feat(toolchain): host-aware tool resolution with spec + prefix env
Generalise external-tool lookup so a cross/host build finds the right
binaries:

- target: HostTarget detects the host OS from ParamStr(0) (a '.exe' suffix
  means Windows, incl. under wine) instead of assuming linux; add
  ExecutableExtension(target).
- uToolchain: TToolSpec (ordered candidate basenames, a cross-triple
  prefix, and a HostTool flag) + ResolveSpec resolve a tool by env
  override, then $BLAISE_TOOLCHAIN_PREFIX + name, then the cross prefix on
  $PATH, then bare name — each probe appending the host exe extension.
  HostTool distinguishes host tools (run anywhere, target via flags) from
  target tools (must be the target's own binary; no host fallback when
  cross). TrySingleName now uses the real host extension.
- driver: TBackendDriver.DescribeTools(target) declares a backend's tools
  (base = the shared linker: cc/clang or the mingw cross-linker for a
  Windows target); ToolPath resolves one by name; LinkViaToolchain links
  through it. Self.DescribeTools for virtual dispatch.

Native sret codegen fixes (folded in so this commit bootstraps): the
toolchain code is the first in the compiler's own source to build a record
via a function whose body does SetLength on a dynamic-array Result field,
and to pass a record-returning method result directly as a const-record
argument.  Both miscompiled on the native x86-64 backend (QBE was correct),
so a native-compiled compiler could not bootstrap at this commit:

- EmitLValueSlotAddr: an l-value field slot on a local record used a raw
  leaq, but the sret-function Result slot holds a POINTER — route through
  EmitLocalRecordBase so the pointer is loaded before adding the field
  offset (fixes SetLength(Result.DynField, N)).
- EmitArgHoist: a record-returning method-call argument was materialised
  via EmitExprToEax, which has no sret path for method calls — allocate the
  buffer and drive EmitMethodSretCall directly, mirroring the function path.

Tests:
- cp.test.toolchain: ResolveSpec resolution order, host-tool vs target-tool
  cross-suppression, fallback naming, and the host/extension helpers.
- cp.test.e2e.recordret: regressions for both native sret fixes (both
  backends).
- cp.test.codegen: native backend also emits the _BlaiseInit startup call
  (the existing assertion only covered QBE).

A third, pre-existing native sret bug (sret-call result + const-string arg
in the same call) surfaced while writing the toolchain tests; it is
independent of this work and logged in bugs.txt.

Backend-neutral feature; native fixes are x86-64-only.
2026-06-17 00:44:35 +01:00
.github ci: bump deprecated actions to Node 24 majors 2026-06-16 18:09:03 +01:00
compiler feat(toolchain): host-aware tool resolution with spec + prefix env 2026-06-17 00:44:35 +01:00
docs feat(strutils): clean literal replace API — Replace (first) + ReplaceAll 2026-06-16 23:49:30 +01:00
plugins chore(license): relicense from BSD-3-Clause to Apache 2.0 + Runtime Library Exception 2026-05-03 19:45:29 +01:00
runtime fix(rtl): run one-time RTL setup via a _BlaiseInit startup hook 2026-06-17 00:10:53 +01:00
scripts test(native): add internal-assembler conformance guard 2026-06-16 00:50:18 +01:00
stdlib feat(strutils): clean literal replace API — Replace (first) + ReplaceAll 2026-06-16 23:49:30 +01:00
tests test(bench): record TList<TObject> scan speedup from ARC elision 2026-05-21 17:28:44 +01:00
tools feat(properties): default array property — Obj[I] sugar 2026-06-16 14:48:38 +01:00
vendor/qbe vendor: update QBE from v1.2 to v1.3 2026-06-02 16:54:51 +01:00
.gitignore chore: gitignore docs/opdf-emission-design.adoc (local FYI note) 2026-06-09 17:33:44 +01:00
LICENSE chore(license): relicense from BSD-3-Clause to Apache 2.0 + Runtime Library Exception 2026-05-03 19:45:29 +01:00
NOTICE chore(license): relicense from BSD-3-Clause to Apache 2.0 + Runtime Library Exception 2026-05-03 19:45:29 +01:00
project.xml feat(tools): add bif-coverage verifier for AST/encoder/decoder drift 2026-06-08 00:27:24 +01:00
README.adoc docs: add CI build status badge to README 2026-06-16 18:19:10 +01:00

= Blaise Pascal Compiler
:icons: font
:source-highlighter: rouge

image:https://github.com/graemeg/blaise/actions/workflows/bootstrap.yml/badge.svg["Build status", link="https://github.com/graemeg/blaise/actions/workflows/bootstrap.yml"]

**The Pascal you love, reimagined for the modern era.**

Blaise is a next-generation Object Pascal compiler built from the ground up to eliminate decades of legacy baggage. It prioritizes developer productivity, memory safety, and high-performance execution.


== ✨ The Vision

The Object Pascal ecosystem has two options: Embarcadero Delphi (proprietary,
Windows-first) and Free Pascal (open source but carrying 30 years of accumulated
complexity — five language modes, five string types, and thousands of include files).

This compiler takes a different approach:

* *One language mode.* No `{$mode}` switches; no legacy dialect support.
* *One string type.* UTF-8 reference-counted string and 0-based indexing. `RawBytes` for binary data.
* *One memory model.* Automatic reference counting applies uniformly to
  strings, classes, and interfaces. No manual/auto split between `TObject`
  and `TInterfacedObject`; `[Weak]` breaks cycles. `Free` is retained as a
  synonym for immediate release.
* *Clean interfaces.* No COM GUIDs; interface dispatch via compile-time vtable mapping.
* *Reified generics.* Monomorphization at compile time — no type erasure.
* *Modern build system.* PasBuild with `project.xml`; no makefiles.
* *First-class debugger.* OPDF is the default debug format; DWARF is not required.

See link:docs/design.adoc[docs/design.adoc] for the full architecture and
implementation plan.

The result — A modern, cross-platform Object Pascal compiler targeting native code
via two backends: https://c9x.me/compile/[QBE] (the default, production-proven
backend) and a direct native x86-64 code generator (in active development,
approaching feature parity). Single language mode, single string type,
zero-GUID interfaces, reified generics, and first-class
https://github.com/graemeg/opdebugger[OPDF] debug format support.


== 🚀 Project Status

* **Self-Hosting:** Yes. Blaise bootstraps and recompiles itself with byte-for-byte fixpoint. FPC is no longer required — the entire toolchain runs on Blaise alone.
* **Testing:** 3172 tests and growing (Test-Driven Development from day one). The test suite itself compiles under Blaise.
* **Backends:** Two code-generation backends — QBE (default, production) and a direct native x86-64 backend (in active development, approaching feature parity with QBE).


[cols="1,3,1", options="header"]
|===
| Phase | Goal | Status

| 1
| Bootstrap pipeline — Hello World on Linux x86_64 via PasBuild
| Complete ✅

| 2
| Type system — classes, records, ARC, exceptions
| Complete ✅

| 3
| Generics + zero-GUID interfaces
| Complete ✅

| 4
| OPDF debug info emission
| Complete ✅

| 5
| Self-hosting
| Complete ✅

| 6
| Language improvements + expand RTL & StdLib + bug fixing
| In-Progress

| 7
| Native backend feature parity + Windows + macOS ARM64
| In-Progress

| 8
| LSP + VS Code extension
| Planned

| 9
| Migration analyser for FPC/Delphi codebases
| Planned
|===

== What Is Dropped From Classic Pascal

[cols="1,3", options="header"]
|===
| Feature | Reason for removal

| `ShortString`, `AnsiString`, `WideString`, `UnicodeString`
| Replaced by a single UTF-8 reference-counted `string` type

| `with` statement
| Source of hard-to-diagnose symbol resolution bugs; breaks static analysis

| Old-style `object` types
| Use `record` (stack/value) or `class` (heap/reference) instead

| COM-style interface GUIDs
| Interface dispatch via compile-time vtable; GUIDs are unnecessary complexity

| Multiple language modes
| One dialect, maintained well, beats five dialects maintained poorly

| `assign`, `reset`, `rewrite`, `blockread`
| Replaced by a stream-based I/O RTL

| `TObject` vs `TInterfacedObject` split
| One unified class model under automatic reference counting; `[Weak]`
  breaks cycles
|===

== 📢 Community

The core architecture is still being finalised, so the project is not yet
accepting code contributions. Feedback on language design, syntax choices, and
the future direction of Blaise is very welcome — please use the
https://github.com/graemeg/blaise/discussions[Discussions] tab on GitHub.


== Repository Layout

This project uses PasBuild's multi-module layout. Each subdirectory with a
`project.xml` is an independent module; the root `project.xml` is the aggregator.

....
project.xml                       Root aggregator (packaging=pom)
│
├── compiler/                     The compiler binary (packaging=application)
│   ├── project.xml
│   └── src/
│       ├── main/pascal/          uLexer, uParser, uAST, blaise.codegen.qbe, blaise.codegen.native.*, ...
│       └── test/pascal/          Test suite (blaise.testing, compiled by Blaise)
│
├── runtime/                      Always-linked runtime (packaging=library)
│   ├── project.xml
│   ├── Makefile
│   └── src/
│       ├── main/asm/              Platform assembly (setjmp, atomics, UTF-8)
│       ├── main/pascal/          system.pas, blaise_str.pas, blaise_arc.pas, ...
│       └── test/pascal/          Runtime tests (punit, compiled by Blaise)
│
├── stdlib/                       Standard library — opt-in via uses clause
│   ├── project.xml
│   └── src/
│       └── main/pascal/          sysutils.pas, classes.pas, math.pas, ...
│
├── tools/
│   └── migration-analyser/       FPC/Delphi migration report tool (packaging=application)
│       ├── project.xml           depends on compiler module
│       └── src/
│           ├── main/pascal/
│           └── test/pascal/
│
├── vendor/qbe/                   Vendored QBE backend source (pinned, built from source)
└── docs/                         Design documents and specifications
....

PasBuild compiles each module to its own `target/` subdirectory. Build output is
never committed to the repository.

== Building

=== Prerequisites

* A previously released Blaise binary (see `releases/`)
* https://github.com/graemeg/pasbuild[PasBuild]
* A C compiler (`gcc` or `clang`) for building the vendored QBE backend and linking
* GNU `make` for the runtime build

NOTE: FPC is *not* required. Blaise is fully self-hosting — each release binary
compiles the next version. The bootstrap chain starts from the binary in
`releases/`.

=== Bootstrap from a release

The runtime build compiles its Pascal units (`blaise_str.pas`, `blaise_arc.pas`,
`blaise_sys.pas`) using the Blaise binary at `compiler/target/blaise`. On a
clean checkout that binary does not exist yet, so the release binary must be
passed explicitly via the `BLAISE` make variable.

[source,shell]
----
# 0. Build the vendored QBE backend (once-off — not needed again unless
#    you update vendor/qbe/)
cd vendor/qbe && make && cd ../..

# 1. Build the runtime using the release binary (BLAISE= avoids chicken-and-egg)
cd runtime && make BLAISE=../releases/v0.7.0/blaise && make install && cd ..

# 2. Compile the compiler using the latest release binary
releases/v0.7.0/blaise \
  --source compiler/src/main/pascal/Blaise.pas \
  --unit-path compiler/src/main/pascal \
  --unit-path runtime/src/main/pascal \
  --unit-path stdlib/src/main/pascal \
  --emit-ir > /tmp/blaise.ssa

# 3. Assemble and link
vendor/qbe/qbe -o /tmp/blaise.s /tmp/blaise.ssa
gcc -o compiler/target/blaise /tmp/blaise.s compiler/target/blaise_rtl.a
----

Once `compiler/target/blaise` exists, subsequent RTL rebuilds (`make && make install`)
work without the override. The QBE build in step 0 is a one-off and does not
need to be repeated when rebuilding the compiler.

=== Bootstrap a development checkout

The procedure above works while the latest release binary is new enough to
compile the current source. Between releases that ceases to hold: once a commit
teaches the parser a new feature and a later commit uses it in the
runtime/compiler, the release binary can no longer build `master` directly.

`scripts/rolling-bootstrap.sh` rebuilds the chain commit-by-commit from the last
release binary up to the checked-out revision, producing a working `-pre`
bootstrap binary. See link:scripts/BOOTSTRAP.adoc[scripts/BOOTSTRAP.adoc] for the
prerequisite (placing the release binary under `releases/`) and usage.

=== Build via PasBuild

PasBuild can drive the full compile and test cycle using a Blaise binary:

[source,shell]
----
pasbuild compile -m blaise-compiler --compiler compiler/target/blaise
pasbuild test -m blaise-compiler --compiler compiler/target/blaise
----

=== Run tests

[source,shell]
----
pasbuild test -m blaise-compiler --compiler compiler/target/blaise
----

=== Verify self-hosting fixpoint

After any compiler change, verify that the compiler reproduces itself:

[source,shell]
----
./scripts/fixpoint.sh
----

This generates stage-2 and stage-3 IR and confirms they are identical.

=== Running the compiler

Once built, the compiler binary is at `compiler/target/blaise`.

[source,shell]
----
# Compile a single-file program (QBE backend — default)
compiler/target/blaise --source Hello.pas --emit-ir > Hello.ssa
vendor/qbe/qbe -o Hello.s Hello.ssa
gcc -o Hello Hello.s compiler/target/blaise_rtl.a

# Compile via the native x86-64 backend (no QBE step)
compiler/target/blaise --source Hello.pas --backend native --output Hello

# Compile with unit search paths
compiler/target/blaise --source MyApp.pas \
  --unit-path src/units \
  --emit-ir > MyApp.ssa

# Emit QBE IR only (useful for debugging the compiler itself)
compiler/target/blaise --source Hello.pas --emit-ir
----

== Licence

Apache License v2.0 with Runtime Library Exception. See link:LICENSE[LICENSE].


---
*Built with ❤️ for the Pascal community by Graeme.*