A TypeScript-types-only WebAssembly runtime

This is a WebAssembly runtime implemented purely in TypeScript types. The basic idea is that you can turn C code (or just straight WebAssembly) into a TypeScript type (as in, with no JavaScript runtime code) that will compile the instructions and return a result.

It can run Doom

This engine was built to service a project that aimed to demonstrate why Doom can't run in TypeScript types. Well. The funny thing is.. It can. There's a video about it on the MiTS YouTube, and much much more to come soon to give more context on why and how this was made.

Should I submit a PR to make this even better?

No, probably not. What you’re viewing in this repo is basically an active crime scene. There’s blood splattered about and although it’s clear the murder weapon is still in the house… it’s not clear exactly where in the house it might be.

It might sounds strange, but I, @dimitropoulos, have absolutely no emotional attachment to this code and negative-BigInt-zero interest in making it do even more. It runs Doom. That's enough. We can all rest easy now. If you'd like to get it to run Crysis - I'll happily pass the project off to you, but if you look at the commit history you're going to find I completely stopped working on it it the literal second it completed the mission. I will, however, gladly spend a few hours on a call or something with anyone that might like to take this to the "next level" in the future, whatever you determine that to be. It just won't be me.

I have questions, thoughts, suggestions, ideas, etc.

Please don't open an issue - just come on the MiTS Discord's #doom channel and we'd be glad to chat about it.

Tour of Ridiculous Types

In case you're here just heckle, here's some nightmare fuel for you:

ShiftRight: this whole file has silly things, but hey, sometimes you gotta do whatcha gotta do.
Add: this is the cornerstone of the arithmetic in the application. Upon seeing this for the first time, some people have said "I see TypeScript types on the screen, but I don't quite see where addition is taking place". Fair. It's there, though.
Divide was by far the hardest instruction to implement to get it up to 64 bits. @teamchong gets all the credit for this one. To get there, we had to build it up one bit at a time to see where it hit performance limitations with the division playground.
some of the binary helpers are sorta artsy to look at fullscreen.
final-doom-pun-intended contains the files where the finish line was crossed. While it was chugging away, we made mockups that demonstrated what it would look like when complete. As it often goes, the mockups ended up being the real thing in the end, haha.
david-blass-incredibleness, so-named because of a very important bit of insight that @ssalbdivad provided which caused an explosion of progress, is the main dashboard for development of individual tests.
conformance-tests for the full loop (i.e. from C to WASM to types) as well as from straight WASM to types can be found here. They're called conformance tests because the same inputs are tested agains the JavaScript built-in WebAssembly runtime, which was the way I made sure this engine's behavior is correct.
Many of the instructions were surprisingly straightforward but some of the control flow instructions have some meat on the bone.
bootstrap shows how to boot the WebAssembly runtime within TypeScript types.
There are probably more fun ones, but the last I'll mention is that you can find some of the core primitive types here and the core "how does the state machine actually chug" here.

What exact WebAssembly instructions does it implement?

These ones, all written while reading the WebAssembly Instructions spec:

block
br
br_if
br_table
call
call_indirect
drop
else
f32.reinterpret_i32
f64.reinterpret_i64
global.get
global.set
i32.add
i32.and
i32.clz
i32.const
i32.ctz
i32.div_s
i32.div_u
i32.eq
i32.eqz
i32.extend_16_s
i32.extend_8_s
i32.ge_s
i32.ge_u
i32.gt_s
i32.gt_u
i32.le_u
i32.le_s
i32.load
i32.load16_s
i32.load16_u
i32.load8_s
i32.load8_u
i32.lt_s
i32.lt_u
i32.mul
i32.ne
i32.or
i32.popcnt
i32.reinterpret_f32
i32.rem_s
i32.rem_u
i32.rotl
i32.rotr
i32.shl
i32.shr_s
i32.shr_u
i32.store
i32.store_16
i32.store_8
i32.sub
i32.trunc_f32_s
i32.trunc_f64_s
i32.trunc_f64_u
i32.wrap_i64
i32.xor
i64.add
i64.and
i64.clz
i64.const
i64.ctz
i64.div_s
i64.div_u
i64.eq
i64.eqz
i64.extend_i32_s
i64.extend_i32_u
i64.ge_s
i64.ge_u
i64.gt_s
i64.gt_u
i64.le_s
i64.le_u
i64.load
i64.load16_s
i64.load16_u
i64.load32_s
i64.load32_u
i64.load8_s
i64.load8_u
i64.lt_s
i64.lt_u
i64.mul
i64.ne
i64.or
i64.popcnt
i64.reinterpret_f64
i64.rem_s
i64.rem_u
i64.rotl
i64.rotr
i64.shl
i64.shr_s
i64.shr_u
i64.store
i64.store_16
i64.store_32
i64.store_8
i64.sub
i64.xor
if
local.get
local.set
local.tee
loop
memory.grow
memory.size
nop
return
select
unreachable

Additionally, like many runtimes, a few "synthetic" instructions were created that are not according to any WebAssembly standard, but are sorta convenience features

synth.end_block
synth.end_func
synth.end_loop
synth.halt