The Future of fpGUI: it's getting a new engine🚀

[graemeg]

So here's the thing. I've built a custom cross-platform GUI toolkit, a project build system (PasBuild) to unify Object Pascal projects, and a dedicated debug format (OPDF) with a reference CLI debugger. I’m also currently building an IDE to bring all of these pieces together into one optimised development environment.

So what's the next big thing?

Years later, I’ve come to the same conclusion as Martin Schreiber (MSEide-MSEgui). I only wish he’d shared more of his rationale in the mselang README—it would have been great to compare notes. With FPC development effectively stalled (no major releases in over five years) and my continued frustration with the resistance to language evolution and the team mentality (excluding one or two members), I decided to start my own "modern Pascal compiler."

It isn't based on mselang, but it shares similar goals. It currently uses a QBE backend, with an LLVM backend (the industry gold standard for optimised code generation) coming soon to support even more platforms.

It’s early days and plans can change, so I’m keeping the name under wraps for now, but here is the vision for the new Blaise Compiler:

• Zero Legacy: Stripping away 1980s baggage to focus on modern syntax.
• Unified Strings: A single UTF-8 string type—no more juggling five different types in 2026.
• Full ARC: Automatic Reference Counting for strings, interfaces, and objects for seamless memory management.
• Weak References: To prevent cycles and improve the ARC system.
• Type Clarity: Eliminating the "Char vs. Byte" confusion once and for all.
• Consistency: No more messy language modes or feature switches.
• Safety: Optional support to prevent null pointer exceptions.
• Modern Features: First-class generics and native OPDF support.
• Tooling: Integrated CLI debugger and PasBuild as the native build system.
• Migration Path: A built-in analyser to help transition FPC/Delphi codebases.

Thanks to the help of AI as a coding partner, this isn't a "ten-year dream" any more. I design and architect; the AI assists in implementation. Every line is human-reviewed and verified through Test-Driven Development (TDD) from day one.

So when does this start? It already has! 🎉

One week in, and a boatload of tokens later, my new compiler is officially self-hosting as of today! 🥳 It can now bootstrap and recompile itself over two consecutive stages with a byte-for-byte exact match. I already have a test suite of over 860 tests and growing.

While it only supports "basic" Pascal at this moment, the foundations for ARC, generics, records with methods, classes, and interfaces are already live and tested.

We’ve spent years working around the limitations of the past. It’s time we had a toolchain that works for us, not against us. I can't wait to show you what's next.

Onwards,
Graeme

[Update 29 Apr 2026]: Head over to the official Blaise project page: https://github.com/graemeg/blaise

[andrewd207]

TBH I would love to try out this compiler. I've done some things in kotlin and there are things I love about it. Like Result := case a/b/c type things. or the when keyword. I had some crazy thoughts to try to make the fpc compiler backend part consume kotlin code but then I came to my senses 😰

Generics as core language feature is amazing as well with endless lists of particular item types. I've been using the TFPGObjectList a lot. I submitted a patch once to let generic forwards work but it wasn't applied. Maybe it was a forward for the item type.

TItem = class; // forward

TList = specialize ... <TItem>

TItem = class
  Parent: TList;
  ...

Something Like that. Nope, generic adjacent but no Here

Anyway, super ambitious. I look forward to it. 😃

[graemeg]

I would love to hear more of your language ideas. There are so many languages these days, it's near impossible to keep up. I obviously still want to keep the pascal heritage, but definitely open to evolution.

I'll open up a new git repo for the compiler soon, then more discussions can happen there.

Anyway, super ambitious.

Yeah, I don't know how deep this rabbit hole is going to go. It's by far the largest programming challenge I've taken on. But so far it's been fun, and a massive learning experience.

Fun... Well, except for a few debug sessions, were both AI and I were debugging for almost 2 hours straight, just to find a small 2 line QBE emit code change to fix the issue. 😢 Debugging a compiler is magnitudes harder than debugging fpGUI or PasBuild. It definitely would not be possible [for me] without AI assistance. As much as I love coding myself - AI reads and types faster than I can. 😆

[andrewd207]

in Kotlin things like

fun describeNumber(value: Int): String {
    return when (value) {
        -1 -> "Exactly negative one"                  // simple literal

        0 -> "Zero"                                   // simple literal

        1 -> "The number one"                         // simple literal

        in 2..10 -> {
            // branch with logic
            if (value % 2 == 0) {
                "$value is a small even number"
            } else {
                "$value is a small odd number"
            }
        }

        in 11..100 -> {
            val category = when {
                value < 50 -> "mid‑range"
                else -> "getting big"
            }
            "$value is $category"
        }

        else -> "Some other number"                   // simple literal fallback
    }
}

// for pascal it could use case
message := case x of
  1: 'One';
  2: 'Two';
  3: begin DoSomething; 3; end;
  42: Writeln('The answer to everything');  // error because no result given

or also things like

procedure (Obj: TObject; FooOther: TObject);
begin
  if Obj is TStrings then
  begin  // where it's been established what type it is no typecasting is needed
    Obj.Clear; 
    Obj.Add('1)';
    Obj := FooOther; // now the type is not certain and no longer can be treated as TStrings
  end;
  Obj.Count;; // outside verified block. compiler complains.
end;

Also I love annotations 😁 you can do some really nice stuff with rtti and annotations together

[Alligator-1]

Will your language support creating classes on the stack (without allocating dynamic memory), similar to C++?

[graemeg]

Who knows. 🤷‍♂️ 😉

[Schmitty2005]

When using trig functions with single types, and probably doubles, FPC seemed to have a major bottleneck compared to C. I am just a hobbyist, but I personally thought that was ridiculous considering it is 2026, and FPC has been around for over 25 years. I tested in Delphi CE12. Same issue! I was shocked.

I wanted to create PCM audio with the single type. I didn't need the precision of a double. It looks like FPC/Delphi converted all singles to double while doing the trig functions. Maybe this is a low level x86_64 issue ? No fast intrinsic CPU instructions for single sine ? Single Tanh?

Will your compiler be able to do single precision faster than double precision with expected speed?

As far as I know, single precision is fine for audio and some video work.

[graemeg]

Why FPC/Delphi singles are slow for trig?

The x87 FPU legacy. For decades, x86 compilers routed all floating-point through the x87 FPU, which always operates
internally in 80-bit extended precision — regardless of whether your variable is Single (32-bit) or Double (64-bit).
There was never a "fast 32-bit path" on x87.

SSE2 changed things — but only if the compiler uses it correctly. Modern x86_64 CPUs have SSE/SSE2 scalar instructions
(ADDSS, MULSS, SQRTSS, etc.) that genuinely operate at 32-bit precision and are faster than their 64-bit
counterparts. C compilers targeting x86_64 default to SSE2 and use these. FPC does too for basic arithmetic, but trig
is a different story.

The real bottleneck: libc math functions. Hardware has no native sin/cos instruction on modern x86_64 (the old x87
FSIN instruction is famously slow and avoided). Trig is computed via software polynomial approximations in libc. Here
is the critical point:

• C has two families: sin(double) / cos(double) and sinf(float) / cosf(float) / tanhf(float).
• The *f variants use a shorter polynomial because they only need ~24 bits of mantissa vs ~53 bits. That is a genuine
  algorithmic speedup — fewer multiply-add iterations.
• FPC's Sin(), Cos(), Tanh() etc. in the RTL call the double-precision libc functions internally, converting Single →
  Double → call sin() → Single. You pay the full double-precision cost plus two conversions.
• Delphi does the same thing, hence the identical result.

SIMD is a further gap. A well-optimised C library (glibc, Apple's libm, Intel's SVML) can compute sinf on 4 or 8
singles simultaneously via ADDPS/MULPS. FPC never generates vectorised code for these paths.

This is a straightforward fix when we reach that point. I've added it to my future improvements document, so it's not forgotten. Thanks for mentioning this.

[marcovtje]

* FPC's Sin(), Cos(), Tanh() etc. in the RTL call the double-precision libc functions internally, converting Single →
  Double → call sin() → Single. You pay the full double-precision cost plus two conversions.

Since when does FPC link to libc? Except maybe Apple platforms.

Also look up $excessprecision and -Cfsse2

[graemeg]

Looking at FPC 3.3.1 code.

x86 / x86_64 with FPC_HAS_TYPE_EXTENDED (rtl/x86_64/math.inc:215-246):

function fpc_sin_real(d : ValReal) : ValReal; compilerproc;
asm
  fldt d
  fsin    { x87 80-bit instruction, no libc call }

No libc call. Single is widened to 80-bit Extended, processed by the x87 fsin instruction, then narrowed back. The
precision penalty is actually worse than double — it is 80-bit — but there are no conversions through libc.

AArch64 / ARM / PowerPC / etc. (rtl/inc/cgenmath.inc:186-196):

function c_sin(d: double): double; cdecl; external 'c' name 'sin';  { double precision libc }
...

function fpc_Sin_real(d: ValReal): ValReal; compilerproc;
begin
  result := c_sin(d);
end;

Here ValReal = Double. A Single argument is widened to Double before the call and the Double result narrows to Single
on return. The claim is true for these targets. FPC never calls sinf/cosf — confirmed by a grep of the entire RTL
showing no such calls.

[Schmitty2005]

* FPC's Sin(), Cos(), Tanh() etc. in the RTL call the double-precision libc functions internally, converting Single →

  Double → call sin() → Single. You pay the full double-precision cost plus two conversions.

Since when does FPC link to libc? Except maybe Apple platforms.

Also look up $excessprecision and -Cfsse2

When I had tried these options, $excessprecision off with compiler flag -Cfsse2, it made NO difference. I had heard from others, it also made no difference for them. I do not know why. Intel i7 Haswell. Looking at the math unit, it all got converted and calculated as doubles, then converted back to single.

[fredvs]

Excellent, Graeme, you're a true Pascal lover.
Will your new gem be compatible with the source code developed for FPC?
Will it be possible to compile MSEgui projects with your treasure?

[graemeg]

This might be a hint...

Migration Path: A built-in analyser to help transition FPC/Delphi codebases.

But the true answer is, it's too early to tell. I definitely don't want to rewrite fpGUI from scratch, and I also don't want to ditch all current users of fpGUI that uses FPC.

[Alligator-1]

Another idea is to create equivalents of StringView in C++, Slice in Go, and Span and ReadOnlySpan in C#, and add support at the RTL (compiler?) level.

[Schmitty2005]

Will this be ISO 7185 compatible ? ISO 7185:1990 ?

ISO/IEC 10206:1990 Extended Pascal ?

Just curious...there are reasons to adhere and reasons not to.

[graemeg]

My focus is on developing a modern, productive Object Pascal dialect, so strict ISO compliance isn't currently on the roadmap. I believe it's better to implement one dialect perfectly than to support three partially!

As for the ISO and Extended standards, I understand that FPC supports them, though I haven't personally experimented with those modes.

[graemeg]

The Blaise project has landed ✨ : https://github.com/graemeg/blaise