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

Only as anyone mining the web for esoteric code will attest, anything written in standard C since probably the mid 80s and using only the ANSI C standard library can still be fed to a compiler today and produce perfectly functioning code, taking advantage of every advancement in compiler technology in the 30 years that have followed.

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. C is called "high level assembler" for a reason, just as "asm.js" is called "asm.js" for a reason.

Even if we had some standard binary format for describing software available since the 80s, it would almost certainly lack sufficient descriptive power to capture constructs that could be vectorized, or otherwise transformed using more modern compilation techniques that simply didn't exist at the time. Lowering to a binary form throws all that semantic information away. And the more you add back the more the binary form starts to look like a pointless transformation of the original source code.

Then there is the idea that such a format could ever have been designed in the 80s that would have lasted us to present day. 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.

(Pre-emptively rejecting boring VM counterexamples like Java for reasons that can be extrapolated from what I just described. Every comment on this thread brings it closer to HN's "controversiality" scoring penalty, and I'd very much like for this link to stay on the front page all day)

> 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.

> Only as anyone mining the web for esoteric code will attest, anything written in standard C since probably the mid 80s and using only the ANSI C standard library can still be fed to a compiler today and produce perfectly functioning code, taking advantage of every advancement in compiler technology in the 30 years that have followed.

Have you ever actually tried this? It doesn't work.

I have. When I started at Arbor Networks in the early 00's, we needed a fine-grained timer library that was millisecond-granular and could efficiently manage thousands of scheduled events. I stole mine from the MIT-licensed Athena codebase, which dates back to the '80s.

But was it generated code? I've had pretty bad luck with old scheme/lisp implementations that compile to C.

>I'm not sure why you think asm.js isn't a blob

Because it isn't? It's a perfectly normal set of semantics in a language form on top of regular JS.

>in order to achieve those performance levels that you see in Mozilla, you have to interpret JavaScript as something that is not JavaScript, which requires having a spec in hand, dealing with potentially ambiguous encodings, and interpreting the asm.js as a bytecode, rather than as standard JavaScript.

All of them observations that are BESIDE the point if asm.js is a blob or not.

Actually, asm.js is JavaScript. That is, in fact, much of the point. It's kind of like the PyPy project's RPython: a restricted subset of Python that lends itself well to ahead-of-time compilation and optimization.

This leads to the question of whether (when?) someone will try to port Narcissus to it, potentially leading to a practical self-hosted JavaScript engine. "MonkeyMonkey", they could call it.

It's a blob that has excellent integration with a very well-known interpreted language with good tool support, including some nice debuggers. It looks like it will have a nice foreign function interface. Although not terribly readable, at least you don't have to learn a new assembly language when you really need to examine the object code, and you could easily edit the binary if it helps you debug something. Perhaps you can see the appeal?