Open TheDrawingCoder-Gamer opened 5 months ago
joshgoebel
commented
5 months ago would have unbounded memory
This is not desirable. The WASM runtime has limited RAM on purpose. (feel free to go back and find the issues around it's development and read them)
run WASM code that uses GC.
This is possible now, just compile a binary that has garbage collection. Garbage collection does not require unbounded RAM.
TheDrawingCoder-Gamer
commented
5 months ago I know that it has limited RAM on purpose, the idea is that garbage collected languages tend to use more memory. Right now all languages except for WASM have unbounded memory.
The idea of "running WASM code that uses GC" is that it moves the GC from the binary into TIC-80 itself, providing more space in the binary for actual code. GCs can become pretty large so it eats into the already smaller 256Kb limit.
I can see it not having unbounded memory, but it should probably still have more memory than non-GC'd wasm.
As an example, right now Go's minimum file size of WASM files is 2mb. This is because of the bundled garbage collector. Once Go implements WASM with GC their binaries could possibly be small enough to fit into tic80.
this is more of an upstream issue and/or would require swapping out the WASM library used, but would like to see an option to run WASM code that uses GC. Of course this would likely require using a seperate engine (from my cursory research I couldn't really find one as versatile as wasm3) and likely a seperate script mode would be needed.
This is more of a wishlist item, but this could open up languages that aren't on the current list, but can be compiled to WASM with GC. The idea is that it would be seperate and thus would have unbounded memory and also would have the GC handled on the TIC-80 side, thus meaning that more code could be used for actually doing work in the game.