I hope everyone has had a great summer and gotten some well deserved R&R. In Norway the weather is slowly turning darker and colder, and we are back in the labs at full speed. And we have great news for Quartex Developers!
Finally running
Webassembly (WASM) is probably the feature most QTX developers will be the most excited about, and it has been in the pipeline for quite some time. Already back in January of this year we finished the initial assembler and bytecode emitter, so this was only a matter of time.
What has been missing is to implement a new ‘codegen’ for the compiler, one that turns the AST model the compiler builds in WASM bytecodes rather than JavaScript. That is a massive undertaking covering a large corpus of classes, symbols and features unique to the QTX dialect.
Thankfully Grok-AI and Claude has been exceptionally useful in dealing with all the boilerplate tasks and infrastructure. It helped us setup all the symbol classes and required scaffolding – leaving us to write the fun stuff, like the stack page layout, var param strategy, set implementation, lambda capture and all the small methods intrinsic (and fundamental) to the language. You know, those functions we rarely think about, like now() and TDateTime being compatible with how Delphi and Freepascal encodes the data.
Once the nitty-gritty was handled, the rest was a matter of doing what the JS codegen does, but in webassembly rather than Javascript.
So without further ado: yes we have a fully functional webassembly codegen, one that can spit out both wat (source code) and binary webassembly files. We also added a separate step that emits the JavaScript bridge, the “glue” code you include to make webassembly functions and procedures callable from your QTX applications.
To variant or not to variant
Anyone familiar with webassembly might have noticed that most compilers excludes support for the variant datatype. In Quartex Pascal variant is heavily used by the RTL and plays a huge part in what makes QTX integrate so well with web platforms. A pascal variant under QTX maps directly to a normal JavaScript variable, which means it can hold not just values – but also element and object references. So the variant datatype in QTX works more or less exactly like variants do in Delphi, including the capability to hold object references to objects and interfaces.
Webassembly however, is a completely different beast. It is by nature closer to real machine-code but with one crucial exception: there are no pointers, only weak references (or with records and class instances, offsets into a buffer). This means that datatypes like variant would have to be treated as a conditional record. The codegen would have to emit code that tags the datatype every time you write to the variable, and read that back whenever you use the value (otherwise it would not know how to interpret the data at runtime). This represents a significant overhead in terms of speed, and even then – it would not be compatible with variants coming from JavaScript.
Since the entire point of webassembly is speed, introducing a datatype that utterly defeats that purpose is counter-intuitive. There is also a question of how much use it would see? It is difficult to envision any scenario where using variant under webassembly brings any benefit. It might be that we add variant support later, but for now we dont support it.
New RTL Namespace
Webassembly does not understand the DOM, nor does it have direct access to the DOM or NodeJS modules. This means that any RTL function or class must be re-written to work inside the webassembly sandbox. That is a formidable undertaking, one we at least partially can look to AI to save time. But it will still take time to ensure the same behavior.
The aim is to introduce a new namespace ‘wasm’, clone the existing system namespace and all its units, and then convert every method that relies on the JavaScript runtime into webassembly. This will give our customers a solid foundation to build advanced and powerful libraries.
As of writing we have not started on that task.
Javascript bindings
As mentioned the compiler generates bindings automatically for you. All you have to do is mark your unit level procedures or functions with the external keyword, just like you would in Delphi when writing a DLL. The codegen picks this up and creates the “glue” needed so you can invoke the methods from JavaScript.
As of writing this is a clean Javascript (*.js) file, not a pascal file. But that will change shortly. We will emit a second file, a unit that gives you a clean pascal interface. Literally a drop-in solution to any of your DOM or Node projects.
What about classes?
Both classes, records and ad-hoc structures are supported. However they do not cross over from webassembly to JavaScript. We might expand ‘external classes’ to include WASM in the future – but for now you talk to your WASM through ordinary functions and procedures.
Inside the webassembly though, you can create classes, records, arrays and collections as much as you want. So porting Delphi libraries to webassembly that relies heavily on classes or records should be fairly straight forward.
This is more or less identical to how you would write and use a dll library in Delphi or Lazarus. Same approach, different paradigme.
Having the compiler emit skeleton classes that just invoke it’s webassembly counterpart would just result in bloat.
Early test version
We will be offering a command-line preview of the webassembly compiler for our customers sometime in the coming weeks. First up now is an update that fixes a few things, in the IDE. We have done a lot of work on the ARM / Linux build (issued to beta testers today).
A part of the update includes the SEE (sematic execution engine), a full chatbot engine ready to be dragged & dropped onto your forms or datamodules.
With that out we will turn our attention to getting the webassembly commandline compiler into the hands of our customers – and when we feel its mature enough we will bolt it into the IDE.