Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No, it's not technically native code, nor is it exactly assembly or bytecode. It an IR that browsers can JIT very easily. Which is basically the same thing.

It's interesting to note that x86 and amd64 code isn't even truly "native". They're just bytecode IRs that are interpreted by a CISC virtual machine emulated in microcode running on a RISC cpu that you can't program directly. Everything is an IR. Python is an IR for the thoughts in my head. It's turtles all the way down.



> No, it's not technically native code, nor is it exactly assembly or bytecode. It an IR that browsers can JIT very easily. Which is basically the same thing.

So BF is "basically" native code too, since it can be JITted very easily? In fact, it's much easier to JIT BF than asm.js, so according to your definition it is even more "native" than asm.js.

The way you are using "native" takes away all of its meaning.

> Everything is an IR. Python is an IR for the thoughts in my head. It's turtles all the way down.

It's really not.

Yes, every executable representation is a representation (though we don't usually call representations "intermediate" if they are designed to be executed directly).

But the hand-wavy idea that because two things are both representations they are "basically the same thing" is so far from true that it is the opposite of insight. The truth is that the differences between representations is one of the deepest concepts in compilers and VMs.

For example, the entire difference between asm.js and PNaCl mostly boils down to the differences between their two different representations (a modified LLVM bitcode vs. a JavaScript subset). If these two things are "basically the same" then asm.js and PNaCl are "basically the same" too.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: