Recent

Author Topic: Recommendations for wasm32 backend  (Read 518 times)

temp0

  • Newbie
  • Posts: 1
Recommendations for wasm32 backend
« on: February 06, 2026, 03:47:38 am »
Hi all, working through porting a large Delphi project over to FPC and getting the target for wasm32 wasip1 dialed in.

Quick background, it's a 30 year old codebase with business logic intertwined with Winapi, VLC, devexpress etc. etc., extraction of pure logic not in the immediate future - we have it compiling with compatibility layers for the not supported units.

The final core project is around 500 units, about 450 of which are circularly dependent. I'm relatively new to the Pascal world and don't know how egregious or telling this is, but it's the current reality here. Anyway, onto my questions:

1. Are there recommendations for sticking with a particular compiler/assembler path for wasm32? It seems the default is the internal writer ogwasm but llvm seems like a solid route for maintaining future compatibility.
2. Only on this giant project did it come out there are memory leaks in the wasm32 assembly side - this probably doesn't show up in projects < 100 units but ours were blowing up to 32gb+ around 200 units in. I fixed these in a fork, has anyone ran into similar issues? Was going to try to isolate fixes and put up a merge request
3. Internal assembler created some faulty indirect invoke code. This only reared its head with some very complex dependency and flow control but ended up needing some changes with paraloc to retain params, this was only in the default assembler path. Has anyone run into this before? Errors from the `wasm-validate` tool would show dropped params like `type mismatch in call_indirect, expected [i32, i32] but got []`. It's a little more involved of a change but would like to be able to get that upstream if possible as well.

All in all very enthralled with the world of Pascal, having started diving in last November from the world of JS/TS, C++, C#, Go, etc., but enjoying the journey here, FPC has been a pleasure to work with, thanks to the maintainers for all the hard work.

Cheers.

PascalDragon

  • Hero Member
  • *****
  • Posts: 6356
  • Compiler Developer
Re: Recommendations for wasm32 backend
« Reply #1 on: February 07, 2026, 10:38:15 pm »
1. Are there recommendations for sticking with a particular compiler/assembler path for wasm32? It seems the default is the internal writer ogwasm but llvm seems like a solid route for maintaining future compatibility.

The internal assembly writer is recommended, because LLVM is essentially chasing behind a moving target and having to deal with bugs in LLVM. With the internal assembly writer we “only” have to deal with our own bugs.

2. Only on this giant project did it come out there are memory leaks in the wasm32 assembly side - this probably doesn't show up in projects < 100 units but ours were blowing up to 32gb+ around 200 units in. I fixed these in a fork, has anyone ran into similar issues? Was going to try to isolate fixes and put up a merge request

Fixes for such memory leaks are definitely welcome. I remember MvC saying that he had quite some issues with memory usage during compilation as well.

3. Internal assembler created some faulty indirect invoke code. This only reared its head with some very complex dependency and flow control but ended up needing some changes with paraloc to retain params, this was only in the default assembler path. Has anyone run into this before? Errors from the `wasm-validate` tool would show dropped params like `type mismatch in call_indirect, expected [i32, i32] but got []`. It's a little more involved of a change but would like to be able to get that upstream if possible as well.

If it's only in some specific situations it's likely that the one responsible for the wasm-backend (Nikolay) simply did not encounter this yet. So even if you don't have fixes for them, reducing it to a simple example and reporting it on the bug tracker would help a lot.

 

TinyPortal © 2005-2018