[HN Gopher] Making a budget Pascal compiler to WebAssembly
___________________________________________________________________
Making a budget Pascal compiler to WebAssembly
Author : aldidoanta
Score : 37 points
Date : 2022-02-11 08:40 UTC (1 days ago)
(HTM) web link (faizilham.github.io)
(TXT) w3m dump (faizilham.github.io)
| mikewarot wrote:
| That is quite impressive. I've dug in a little bit, I'll look
| more tomorrow.
|
| Thanks for sharing this.
| Rochus wrote:
| Why WebAssembly? Is this technology really still alive? Having a
| look at https://webassembly.org version 1.0 from 2017 is still
| advertised.
| badsectoracula wrote:
| The site mentions that 1.0 is implemented by four major browser
| engines but the spec that it provides is 1.1 which is still
| being developed (last update was just a couple of weeks ago).
|
| Though it is annoying that you can't find the 1.0 spec - you
| know, the one that actually works - in the site. You can find
| it[0] at W3C by clicking around the W3C links in the site, but
| there isn't a direct link. Also annoying that there isn't any
| downloadable form (the SingleFile extension on Firefox seems to
| work though).
|
| [0] https://www.w3.org/TR/wasm-core-1/
| samwillis wrote:
| While the WASM spec is developing slowly some people (myself
| included) believe it's going to become not just a standard for
| computation and a compiler target in the browser but elsewhere
| too.
|
| First for an example of what is possible with WASM take a look
| at Figma, they have a custom vector graphics rendering engine
| built in C++ compiled to WASM and using WebGL. The performance
| is incredible for a web app.
|
| WASM is going to take over much of the cloud server market as
| well. Initially at the "edge" and cloud functions (see
| CloudFlare workers). But it's increasingly going to be the
| standard deployment target. Rust and C++ have first class
| support for it, over dynamic language such as Python will so be
| able to run under WASM very soon (Python is just about there).
|
| It's basically perfect for app plugins as it's naturally
| sandboxed. More software will provide a WASM plugin
| architecture.
|
| Take a look at WASI (https://wasi.dev/), they are working to
| standardise a system interface for outside the browser.
|
| Finally I also think the embedded market is a possible target
| for it. Many of the places that currently run an embedded Java
| VM will potentially use a WASM system in the future.
| Rochus wrote:
| Thank you for your explanations.
|
| > _but elsewhere too_
|
| I noticed that there seem to be more "elsewhere" than
| "browser" applications of the technology. But we already have
| e.g. the Mono engine with a proven, standardized IL which
| already offers most of the WASM features planned for the
| "elsewhere" use case. The engine can be run with just an
| executable and a core library with less than 10MB on a myriad
| of architectures (see e.g. https://github.com/rochus-
| keller/Oberon/ for a lean application of it). So what is WASM
| expected to bring to the table for this use case we don't
| already have today?
|
| > _a custom vector graphics rendering engine built in C++
| compiled to WASM_
|
| Might be a nice idea, but there are already vector graphics
| libraries with included JIT and GPU backends. So what's the
| core benefit of using WASM here as an intermediate layer?
|
| > _But it's increasingly going to be the standard deployment
| target_
|
| Do you have evidence for this? It has a lot of powerful
| competition, e.g. Go or native Java.
|
| > _I also think the embedded market is a possible target for
| it_
|
| "Embedded" is a very broad term. The vast majority of true
| embedded systems will not be able to afford running a VM, or
| even using dynamic memory - I e.g. do all my STM32 projects
| still in a subset of plain C. All embedded systems suited for
| Linux have a broad choice of proven viable technologies, from
| C to Python; even Mono is a viable solution on such systems.
| badsectoracula wrote:
| > I noticed that there seem to be more "elsewhere" than
| "browser" applications of the technology. But we already
| have e.g. the Mono engine with a proven, standardized IL
| which already offers most of the WASM features planned for
| the "elsewhere" use case.
|
| Well, yeah, that is the thing. The idea and similar tech
| existed ever since P-Code for Pascal (and perhaps earlier)
| and of course the very popular - at the time at least -
| Java and its JVM, all of which predate Mono and IL and
| already had several open source implementations.
|
| However just the tech isn't enough - in fact, if anything,
| the computing history shows that tech is rarely the winning
| factor in what gets accepted and becomes popular, it is
| largely social and political factors. In this case the
| "social" factor _seems_ to be that this isn 't just "more
| 'elsewhere' than 'browser' applications" but actually
| "'elsewhere' _and_ 'browser' applications". The fact that
| browsers support WebAssembly natively (as opposed through
| some plugin like it was done for JVM/IL/Flash/etc - ie.
| similar tech) is a big social and political boost that it
| has. This is where the hype currently comes from.
| sirwhinesalot wrote:
| Pretty much agreed, it comes down to a discussion I had
| why before C was the only real standard for language
| interoperability, and nothing else could ever be since
| there's no pressure for the language implementers to
| adopt anything else, because everyone else is using plain
| C as the only officially supported glue as well.
|
| (OS vendors can have their own little things but it
| doesn't matter because it will never be adopted outside
| the OS and will only ever be used to talk to the OS).
|
| This changes with WASM because if languages want to run
| in the browser, they need to target WASM, and suddenly
| there's a new standard that can put as much pressure in
| the language implementations as the C standard. This is
| the second time this has happened in history and I'm
| quite hopeful WASM and WASI catch on since C is complete
| jank as a glue language (even if it's used by everyone).
|
| It all comes down to popularity and politics.
| Rochus wrote:
| > _Java and its JVM_
|
| WASM shares more ideas with CIL than the JVM, especially
| when we have a look at the WASM proposals in progress.
| CIL and Pascal P-Code in contrast to JVM support e.g.
| value objects which supports applications with less
| dynamic memory management; JVM requires a dynamic
| allocation for each fly speck and thus powerful
| compacting collectors to cope with it. In WASM the memory
| management strategy is up to the application.
|
| > _The fact that browsers support WebAssembly natively_
|
| I was referring to the "elsewhere" case, where WASM seems
| to flourish, not the browser. And the social factor is
| definitely important, but I'm more interested what WASM
| is supposed to deliver we don't already have on a
| technical level.
| hkalbasi wrote:
| cygx wrote:
| _So what is WASM expected to bring to the table for this
| use case we don 't already have today?_
|
| It's the latest iteration of Java Applets, Flash,
| Silverlight, PNaCL, ...
|
| If something gets re-invented over and over again, there
| clearly is a niche to fill.
|
| _" Embedded" is a very broad term. The vast majority of
| true embedded systems will not be able to afford running a
| VM, or even using dynamic memory._
|
| Note that since 2007, Blue Ray players are required to run
| a JVM to support the 'bonus view' feature. The number of
| devices beefy enough to run VMs has only grown since.
| Rochus wrote:
| > _It 's the latest iteration of Java Applets, Flash,
| Silverlight, PNaCL,_
|
| My question was about the "elsewhere" use case; I'm
| familiar with the original intention of WASM, and the
| technologies you mention are well covered by HTML5 and JS
| today.
|
| > "The number of devices beefy enough to run VMs"
|
| That's not the point. The point is that industry will
| rather use a cheep microcontroller still today if there
| is no justification for something more powerful, and
| these controllers cannot afford VMs or dynamic memory
| management. Of course there are always people running
| MicroPython or friends on MCUs, but this is a niche.
| tormeh wrote:
| I think they meant embedded as in "Windows Embedded
| Edition".
| cygx wrote:
| _the technologies you mention are well covered by HTML5
| and JS today_
|
| Browser vendors could have decided to choose the pure
| Javascript route (eg asm.js, SIMD.js), but for now have
| decided to throw their weight behind WASM instead:
| SIMD.js got canned in 2017, whereas SIMD support for WASM
| shipped in browsers last year.
|
| Regarding your second point about embedded devices, I can
| easily imagine WASM being used in the class of devices
| targeted by Java ME[1]. I'll of course happily defer to
| people who actually know something about the topic: If
| you think there's no legitimate use case for WASM in that
| space, so be it.
|
| [1] https://en.wikipedia.org/wiki/Connected_Limited_Devic
| e_Confi...
___________________________________________________________________
(page generated 2022-02-12 23:01 UTC)