[HN Gopher] Show HN: Compiling C in the browser using WebAssembly
___________________________________________________________________
Show HN: Compiling C in the browser using WebAssembly
Author : syrusakbary
Score : 95 points
Date : 2024-10-07 16:24 UTC (6 hours ago)
(HTM) web link (wasmer.io)
(TXT) w3m dump (wasmer.io)
| Retr0id wrote:
| > note: it requires a 100MB download
|
| Is this how big a clang toolchain usually is?
| syrusakbary wrote:
| The Clang WASI SDK weights about 100Mb compressed. We optimized
| things a bit but still have a way to go (we are not yet
| compressing in the network). I believe we can serve everything
| in about 30Mb
| 01HNNWZ0MV43FF wrote:
| MB, right? Mb is megabit
|
| I only have to bring this up because network providers still
| insist on measuring bits
| kevin_thibedeau wrote:
| They insist on it because it is the proper way to measure
| data rates on serial bit streams where out-of-band encoding
| doesn't divide up on octet boundaries.
| corysama wrote:
| Is it possible/already existing to have interactive C++ lessons
| where the user's C++ code is compiled an run client-side in a web
| page?
| fwip wrote:
| Definitely been possible for at least 5 years now. Would
| probably be a weekend project now.
| legobmw99 wrote:
| See: emception
|
| https://github.com/jprendes/emception
| halb wrote:
| Absolutely! You can even run clang in wasm targeting x86_64,
| and then emulate the resulting program using the blink x86_64
| emulator.
|
| I'm working on something similar, where students can compile
| intel assembly and run it client-side:
| https://github.com/robalb/x86-64-playground
| marmaduke wrote:
| Couldn't a tcc or similarly simple C compiler be used instead of
| a 100MB Clang? Where's the C to wasm compiler hiding?
| kachapopopow wrote:
| clang can target wasm already.
| syrusakbary wrote:
| The whole LLVM toolchain is a bit big. I think we can reduce
| much more the size. We actually researched on using tcc but
| unfortunately tcc doesn't have a wasm backend (for generating
| wasm output). It would be awesome if they added it!
| fuhsnn wrote:
| Check out https://github.com/tyfkda/xcc, I've only used the
| native backend, but it's small and fast.
| syrusakbary wrote:
| Nice! I didn't know the project. Thanks for sharing!
| mananaysiempre wrote:
| One issue with Wasm is you essentially can't target it with a
| single-pass compiler, unlike just about any real machine. Wasm
| can only represent reducible control flow, so you have to pass
| your control-flow graph through some variation of the
| Relooper[1,2]. I don't know if upstream tcc can do that (there
| are apparently some forks?..).
|
| [1] http://troubles.md/why-do-we-need-the-relooper-algorithm-
| aga...
|
| [2] https://medium.com/leaningtech/solving-the-structured-
| contro...
| titzer wrote:
| > you essentially can't target it with a single-pass
| compiler,
|
| That might be true if your source language has goto, but for
| other languages that start with structured control flow, it's
| possible to just carry the structure through and emit Wasm
| directly from the AST.
| alexdovzhanyn wrote:
| This is true. In Theta (https://github.com/ThetaLang/Theta)
| this is exactly what we do -- no need for more than one
| pass for the WASM codegen.
| mananaysiempre wrote:
| Sure, I was speaking in the context of C specifically. (In
| non-simplistic compilers, you may not want to preserve the
| source structure anyway--e.g. in Scheme or Lua with tail
| calls all over the place.)
| halb wrote:
| If all you want to do is compile and run c code in the browser
| you could run tcc in the blink x86_64 emulator, running in
| wasm. It would take ~300Kb, less than the js & css used in the
| average webpage
| gnulinux wrote:
| I recently wanted to use tcc for a homebaked programming
| sideproject and was surprised to find it's no longer supported
| anymore, at least not by Fabrice Bellard. Upstream git still
| has some light activity but no releases. I wasn't sure how good
| of an idea it is to rely on it as a code generator.
| stefanos82 wrote:
| It's alive and kicking my friend
| https://repo.or.cz/tinycc.git/shortlog
|
| We wait for grischka to decide when to announce a new release
| https://lists.nongnu.org/archive/html/tinycc-
| devel/2024-10/m...
| CyberDildonics wrote:
| 100MB on every page refresh just to compile C is a pretty bold
| direction to go in.
| jampekka wrote:
| Except if/when it's cached.
| adastra22 wrote:
| I don't want my cache requirements ballooning by 100mb.
| legobmw99 wrote:
| If what I want is not an executable but a shared library, does
| this get me anything?
|
| I currently have a use case that uses a server running an
| emscripten build (using SMODULARIZE and some exports, I suppose
| it's not a true dylib)
| Muromec wrote:
| Importing a wasm module from a wasm module is (non)surprisingly
| impossible to do -- you have to have a linker, abi and all
| that.
| okwhateverdude wrote:
| It is possible provided some care. I was looking into this
| with WAForth which compiles the wasm and loads it via a host
| function (ie. it is the hosts responsibility to make it
| available). I wanted to enable dynamic loading of words from
| disk which requires some book keeping and shuffling a bunch
| of bytes around during compilation to write out the bits
| necessary to have the host do that linking. It isn't
| impossible to do, just tedious and in my case, having to
| write it in WAT is a pain.
| whytevuhuni wrote:
| Now all this needs is a simple OS running in a browser, that can
| edit and compile itself, post the resulting binary onto a WebDAV
| somewhere, and reload itself from there.
|
| Then it becomes a fully self-sustaining OS that can live forever
| in a browser.
| jauntywundrkind wrote:
| And then use webrtc (or ideally someone can revive a
| webtransport-p2p _please_!) to serve itself from a page to
| other people.
|
| Ideally http3 over webtransport-p2p!
|
| Then add some network discovery so we can advertise & find
| what's available on our networks!
| dangerwill wrote:
| Very interesting idea but I have to say that those goals are
| not possible with a simple OS, at least by OS definitions of
| simple :P
| whytevuhuni wrote:
| The old https://webassembly.sh/ and the new
| https://wasmer.sh/ came a long way already.
|
| All you need is a virtual filesystem of some sort, a way to
| download, a way to upload, an editor, a compiler, and a VT100
| JS library. We already have WASI for the rest.
|
| If the JS is too undesired, then perhaps go the old
| framebuffer graphics mode (e.g. a region of the WASM memory
| that is interpreted as an ASCII screen, or maybe even as a
| full bitmap buffer). Then JavaScript side just needs to
| forward keyboard/mouse into memory and that screen region out
| of memory.
| Arshia001 wrote:
| The framebuffer idea is used in this wasm doom port:
| https://github.com/diekmann/wasm-fizzbuzz/tree/main/doom
|
| WASIX already does all the other stuff you mentioned,
| including in the browser. The one thing it's missing is
| GUI, mainly because there's no standard GUI interface in
| POSIX.
| d_philla wrote:
| Check out Jeff Lindsay's Wanix project: https://wanix.sh/
| egnehots wrote:
| It's pretty misleading not to mention the performance overhead.
| That's an obvious downside and quite easy to benchmark. Skipping
| any discussion of performance feels like sweeping it under the
| marketing rug :/
| bilekas wrote:
| > Skipping any discussion of performance feels like sweeping it
| under the marketing rug
|
| Expecting performance while compiling C in the browser feels
| redundant right now though.
| bilekas wrote:
| "Yeah, yeah, but your scientists were so preoccupied with whether
| or not they could that they didn't stop to think if they should."
| ....
| zh2408 wrote:
| What's the use case?
| baanist wrote:
| Like most things in software the use cases are the limits of
| one's imagination. The browser has always been a Turing
| complete development environment so this is just another
| demonstration.
| kylewlacy wrote:
| Very cool! I've been watching the "toolchains in Wasm" landscape
| for a while, and seeing a Clang/LLVM toolchain running in Wasm is
| awesome!
|
| YoWASP has also had an LLVM toolchain working in Wasm for a while
| too[1], although it seems like this version solves the subprocess
| problem by providing an implementation of `posix_spawn` whereas
| the YoWASP one uses some patches to avoid subprocesses altogether
|
| My biggest question marks around this version are about
| runtime/platform support. As I understand it, this toolchain uses
| WASIX, which (AFAICT) works with Wasmer's own runtime and with a
| browser shim, but with none of the other runtimes. Are there
| plans to get WASIX more widely adopted across more runtimes, or
| to get WASIX caught up to the latest WASI standard (preview2)? Or
| maybe even better, bring the missing features from WASIX to
| mainline WASI like `posix_spawn`[2]? I'd love to be able to adopt
| this toolchain, but it doesn't seem like WASIX support has really
| caught on across the other runtimes
|
| [1]: https://discourse.llvm.org/t/rfc-building-llvm-for-
| webassemb... [2]: https://github.com/WebAssembly/WASI/issues/414
| westurner wrote:
| Cling (the interactive C++ interpreter) should also compile to
| WASM.
|
| There's a xeus-cling Jupyter kernel, which supports interactive
| C++ in notebooks: https://github.com/jupyter-xeus/xeus-cling
|
| There's not yet a JupyterLite (WASM) kernel for C or C++.
| zengid wrote:
| Didn't Gary Bernhardt do this in 2014? /sarcasm
| zengid wrote:
| reference https://www.destroyallsoftware.com/talks/the-birth-
| and-death...
| apignotti wrote:
| GCC? That's easy! :-) What about a complete system?
| https://webvm.io
|
| Shameless plug: we are hosting a WebVM Hackathon next week (11-14
| October) over Discord. For more information:
| https://cheerpx.io/hackathon
___________________________________________________________________
(page generated 2024-10-07 23:00 UTC)