> But it's not, by your logic a compiler producing machine-generated K&R C in the late 70s would also be a blob. Seeing as generated C is essentially unmaintai

> But it's not, by your logic a compiler producing machine-generated K&R C in the late 70s would also be a blob. Seeing as generated C is essentially unmaintainable and unsuitable to serve as a source language, then yes. > Native Client proponents and similar such "VM fundamentalists" are effectively claiming that we can invent such a format, when it has never been done before in the history of computer science. I'm confused. Asm.js is an ASCII bytecode. We have plenty of other examples of abstract bytecode throughout the history of computer science, but they tend to be binary, not ascii. Other than asm.js using a silly encoding for backwards compatibility purposes, what's the difference? > (Pre-emptively rejecting boring VM counterexamples like Java for reasons that can be extrapolated from what I just described) Huh? Now I'm even more confused. Are you arguing against Java's virtual machine specification, the constraints of its bytecode as defined, or what? Notably, Android converts stack-based Java bytecode to register-based Dalvik bytecode; it's not as if the JVM bytecode strictly defines all conventions in an immutable way, or even that asm.js is all that different in practice. I wanted to address this one last, since it's a bit of a tangent, but it demonstrates the issues of "architecture agnosticism" fairly well: > Those C source files do not, for example, make assumptions about Harvard/von Neumann architecture, stack layout, calling conventions, the presence or absense of SIMD instructions, and so on. That's not exactly true. If pure C is output, then yes, this is the case. In reality, especially with Harvard and modified Harvard architectures, one must take into account architecture differences to achieve reasonable performance, especially on the hardware as developed in the late 70s. For example, there is often limited RAM, in which case one might want to store data in program space. However, C pointers do not, in any standardized way, support annotating the memory space (program, data) in which they live, and code itself can not necessarily portably extract data from program space as to operate on it as if it was in data space. So, for a Harvard architecture, you often either wind up writing non-portable C, or you deal with inefficiencies -- some of which may not be possible to overcome, as there's only so much RAM or data storage to work with.