Mill Computing, Inc. Forums The Mill Architecture The Mill's Competition: Can it still win? Reply To: The Mill's Competition: Can it still win?

Post count: 11

So I didn’t mention the JIT, big deal: that doesn’t materially change the fact that adding WebAssembly into the mix and targeting that instead of what’s already been documented for the specializer is a major waste, and won’t give any advantage to run anything not (usually) targeted to run within the confines of a web browser with 32-bit limitations on a 64-bit processor line. Absolutely, it’s worth having a web browser for the mill processors that handle WebAssembly, and for those that desire to run it outside of the browser as well, why not? It doesn’t have any real benefits outside that context.

I have a huge multiplier of trust with Ivan and his team about their design and implementation decisions over someone second-guessing them as this nonsense is. It makes far more sense to have an intermediate representation that has knowledge of the nature and low-level things a processor line can do, that was generated from a higher-level language that is processor-agnostic, than it does to badly translate some low-level representation of a specific type of virtual hardware and its artificial limitations that was already translated/compiled from the same original higher-level processor-agnostic language and now runs at a fraction of the speed of native code that would be generated by the specializer. This is the code version of playing the telephone game through more than one dissimilar human language, say, Chinese-English-Thai, which loses meaning and efficiency along the way as a result of no 1-to-1 mapping of thoughts.

At least Sweet-16 provided a practical advantage for the Apple 2: a way to execute more compact code on a virtual processor with more registers than the 6502, albeit slower than native. WebAssembly for the Mills only has value as another way to get very limited applications running at a speed and efficiency disadvantage compared to compiling the same code sent through the (say, C++) compiler to Mill without going through a more conceptually-limited VM representation in between. WebAssembly has a very limited use-case scenario in the real world right now, and only makes sense to think about implementing as an entirely separate thing after there is a full OS with web browser for actual Mill CPU hardware already running.