graemeg's comments

On: QBE – Compiler Back End

[graemeg]

Do you know if there is ongoing work to support x86_64 on Windows?

[Willyboar → graemeg]

Yes, windows support already merged to main so it will be in 1.3

On: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

[graemeg]

Every new compiler needs to be bootstrapped by something - unless you head straight into Assembly Language from day1 - but I'm not that crazy!

Yes, Blaise reached self-hosting after just 7 days. Meaning it could compile itself, and was byte-for-byte identical to the bootstrapped version. The language was absolutely barebones, but that's not the goal at that stage. The first (FPC) compiled binary is called the Stage 1 binary. That binary then compiles the compiler code to make a Stage 2 binary (a read Blaise compiler binary). Then Stage 2 compiles the compiler code again to make a Stage 3 binary. Self-hosting is when the stage-2 binary and stage-3 binaries are byte-for-byte identical. Blaise has already achieved that.

I'm currently actively working on removing the FPC and GCC bootstrap requirements. After which Blaise would become it's own bootstrap compiler.

On: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

[graemeg]

fpGUI Toolkit will be made to work with Blaise.

[1] Homepage (terrible looking): https://fpgui.sourceforge.net/ [2] Github repo: https://github.com/graemeg/fpGUI/ The Discussion area has some interesting conversations and screenshots.

On: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

[graemeg]

And FPC also supports interfaces without GUIDs via the {$interfaces CORBA} directive, and it too, supports the Supports(...) construct just fine.

Delphi is just very Windows-centric with a lot of things they do.

On: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

[graemeg]

It's magic! ;-)

Not wanting to go into too much technical details: Blaise's interface system uses TypeInfo pointers as identity tokens. Meaning manually added GUIDs are not needed.

The two Supports() forms. Delphi has two overloads:

// 1. Boolean test function Supports(AObject: TObject; const IID: TGUID): Boolean;

// 2. Combined test + assignment (the useful one) function Supports(AObject: TObject; const IID: TGUID; out Intf): Boolean;

In Blaise, without GUIDs, the second argument is an interface type identifier rather than a GUID. The most natural design is to treat Supports as a compiler intrinsic (like is/as) rather than a library function, because the second argument isn't a runtime value — it names a type.

So Blaise code looks like this:

if Supports(Obj, IFoo) then ... // boolean test if Supports(Obj, IFoo, FooRef) then ... // test + assign fat pointer

[magicalhippo → graemeg]

Ok, so not unlike the RTTI helpers in Delphi then.

Consuming a precompiled binary like a third-party DLL is out of scope then presumably, since TypeInfo pointers won't match.

Which is fair enough, it's not that common these days beyond actual COM usage.

But still not sure exactly why no GUID is a selling point. It's just a bit of metadata.

On: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

[graemeg]

Thank you. fpGUI is 20 years old this year! :-D

On: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

[graemeg]

Yes it has been fantastic to work with QBE so far. It's way simpler than LLVM, giving you about 70% of the LLVM performance, for 10% of the effort. :)

Only downside is Windows support.

On: Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE

[graemeg]

Every new project starts at Day 1. :-)