Nice to see my playground trending! All of this is essentially made possible by the blink engine by @jart: https://github.com/jart/blink/
Which is an x86-64-linux emulator written in a few kb of c code.
There is no Backend server, everything runs locally in the browser in a runtime that weights less than a screenshot of the website itself!
To implement it I modified the blink emulator to run as a C library, and compiled it into a Typescript + WASM module that exposes an emulator API. Then I built a regular web app on top of it.
This is a level lower than https://godbolt.org/ (the "Compiler Explorer") -- think of that site as turning C into assembly, and this site as watching the machine code actually run on virtual hardware.
Is blink an interpreter for x86_64 instructions, or does it compile basic blocks to the host architecture?
I had a look at the source code but I'm not sure how it works. It looks a bit too small (50 kloc C + 6.6 kloc headers) to have code generators for all of the supported host architectures.
Pretty neat idea, but it evaluates the lzcnt instruction incorrectly, so it's possible others are wrong too. If you have access to a real x86_64 processor, you're probably better off just using it, and then you get the power of a full debugger with breakpoints in gdb.
Also, the "Guides" button and the "embed on your website" link on the main page are broken.
This is mostly an educational tool, and it's intentionally designed to present data in a similar way to GDB. The idea is that students will use this tool to learn basic assembly concepts without the extra friction of GDB, and when they are ready they will move to the real tools, where hopefully they will already recognize some of the elements.
I am intentionally not implementing any useful feature beyond single stepping so that students will not remain stuck on a local minimum using this website.
For other architectures, it feels like a missed opportunity to not have an independent WASM build of MAME's debugger, as the whole project could already be built in WASM (although I think the latest versions were broken, as that target isn't actively maintained): https://docs.mamedev.org/initialsetup/compilingmame.html#ems...
I always wondered/wanted to play with a language that comes between Assembly and C (in terms of power/control, granularity, and also ease of use):
* Be just like Asm in every way, but:
* Have standardized architecture-agnostic mnemonics that translate to CPU-specific ones: like something that stands for both MOV on Intel and LDR on ARM.
* Take care of common boilerplate like function call rituals, or the multiple instructions required for loading 64-bit numbers on ARM.
Basically a real language like the ones in "programming simulation" games.
There is no Backend server, everything runs locally in the browser in a runtime that weights less than a screenshot of the website itself!
To implement it I modified the blink emulator to run as a C library, and compiled it into a Typescript + WASM module that exposes an emulator API. Then I built a regular web app on top of it.
> Unlike traditional onlide editors
This is a level lower than https://godbolt.org/ (the "Compiler Explorer") -- think of that site as turning C into assembly, and this site as watching the machine code actually run on virtual hardware.
I had a look at the source code but I'm not sure how it works. It looks a bit too small (50 kloc C + 6.6 kloc headers) to have code generators for all of the supported host architectures.
On the x64-playground website it's just running as an interpreter, inside of web assembly
Also, the "Guides" button and the "embed on your website" link on the main page are broken.
I am intentionally not implementing any useful feature beyond single stepping so that students will not remain stuck on a local minimum using this website.
For other architectures, it feels like a missed opportunity to not have an independent WASM build of MAME's debugger, as the whole project could already be built in WASM (although I think the latest versions were broken, as that target isn't actively maintained): https://docs.mamedev.org/initialsetup/compilingmame.html#ems...
* Be just like Asm in every way, but:
* Have standardized architecture-agnostic mnemonics that translate to CPU-specific ones: like something that stands for both MOV on Intel and LDR on ARM.
* Take care of common boilerplate like function call rituals, or the multiple instructions required for loading 64-bit numbers on ARM.
Basically a real language like the ones in "programming simulation" games.
https://shader-playground.timjones.io/
Additionally you can select CUDA C++ or PTX on compiler explorer.