Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Asm.js

acko.net

Post reply on HN
Print view View original

151–160 of 185 posts

Re: On Asm.js

#151

Post by jheriko »

haberman wrote: post #121
adamtj wrote: post #83

Earlier quoted context omitted.

Asm.js is not Javascript. It's native code! It's not a VM bytecode. It's assembly language, and the target machine is your native CPU. It is sandboxed by the browser. It is present on any computer with a browser and Javascript, which is more computers than have a browser and Java plugin, or any other plugin for that matter. Asm.js is less mature that Java, but it will grow up. It is currently supported by more browse…

If asm.js is not VM bytecode, what is? If asm.js is "native code," then what an example of VM bytecode that is not "native"?

I think your point is "all VM bytecodes are not native".

native means the 'byte code' of your hardware... not some VM?

Re: On Asm.js

#152

Post by wvenable »

haberman wrote: post #145
wvenable wrote: post #141

Earlier quoted context omitted.

Browsers are supposed to compile asm.js code directly into native code before running it. Running it through the VM is the fallback for browsers that don't support it directly.

I can compile BF directly to native code (and actually I did: http://blog.reverberate.org/2012/12/hello-jit-world-joy-of-s... ) so does that make BF native code? The point of these questions is that the GGP's statements are absurd. There is no universe in which asm.js is "native code".

True but I'm replying to a comment stream that describes asm.js code as "portable assembly language" which is a pretty reasonable description.

It's certainly not native code since no CPU exists that can execute asm.js code directly.

Re: On Asm.js

#153

Post by jheriko »

captainmuon wrote: post #51

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java. Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care th…

I'm pretty sure the same argument can be made, but more strongly, for C.

C is massively more cross platform than Java - a JVM implementation often relies on C. C compilers are often the first things implemented for new platforms. C is very close to pure native code - to the point where many equate C/C++ with native. All of Java can be beaten or matched by C performance wise because of the power it gives to leverage the hardware in precisely the same way the JVM can but without (so many) overheads that are designed in.

Re: On Asm.js

#154

Post by jheriko »

vanderZwan wrote: post #132

> "And this is really the biggest contradiction of them all. Tons of people have invested countless hours to build these VMs, these new languages, these compilers, these optimizations. Yet somehow, they all seem to agree that it is impossible for them to sit down and define the most basic glue that binds their platforms, and implement a shared baseline for their many innovations. We really should aim higher than a la…

hot swapping and migration are extremely well solved problems in software... the reason you see it screwed up so much as that few people actually care about it at all.

i'm convinced that fear and lack of understanding are the genuine problems here...

browsers and the webstack are fantastically shoddy and poorly engineered though and that is a serious obstacle... but it doesn't make the problem intractable or hard. 'just' effort.

Re: On Asm.js

#155

Post by hrjet »

thatthatis wrote: post #57
captainmuon wrote: post #51

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java. Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care th…

On the web, when one thing just works, albeit slowly; and another thing requires installation but runs quickly; the thing that just works is likely to win. Unless java gets upgraded to a first class browser component, JavaScript will tend to win. As a product designer, every step I take my user through loses users. Installing java is a big, scary step that I can almost always avoid. The insurmountable issue is that i…

But the cost of installing Java is spread across several apps. So the cost is negligible over time.

It is like saying, if I build a web-app, the user needs to first install the browser. True, but once installed, other web-apps have a zero cost of installation.

Re: On Asm.js

#156

Post by adamtj »

iso-8859-1 wrote: post #138
adamtj wrote: post #83

Earlier quoted context omitted.

Asm.js is not Javascript. It's native code! It's not a VM bytecode. It's assembly language, and the target machine is your native CPU. It is sandboxed by the browser. It is present on any computer with a browser and Javascript, which is more computers than have a browser and Java plugin, or any other plugin for that matter. Asm.js is less mature that Java, but it will grow up. It is currently supported by more browse…

It's assembly language the same way LLVM bitcode is assembly langauge, which means IT ISN'T. It is also represented in text, which means that it is several times larger than it needs to be. Another problem with Asm.js in practice is that it's used with Emscripten which doesn't define the syscalls you talk about. All the DOM/WebAudio/WebRTC/etc API's have to be redone in Emscripten's headers. GL was easy, because WebG…

You are technically correct - the best kind of correct! While I was being a bit loose with my language, I don't think that changes the point.

So maybe it's not an assembly language or a bytecode, but that's a pretty unimportant distinction. Those are all intermediate representations (IR). A good browser will JIT your asm.js IR to machine code in much the same way that a good JVM will JIT your bytecode. An old browser will interpret it more slowly, but it will still work.

Asm.js may be crappy at the moment, but it will get better. It's an easily JITtable IR for the web that's already supported in all browsers, even the old ones. And the security is basically free since that's already being paid for. Yes, it's a bloated text encoding, but gzip is pretty effective. No, it doesn't have great compiler support yet, but Emscripten and equivalent will no doubt have lots of useful headers and emulation and translation libraries very soon. Asm.js is going to win for the same reason that Javascript won: everybody already has it.

Re: On Asm.js

#157

Post by adamtj »

haberman wrote: post #145
wvenable wrote: post #141

Earlier quoted context omitted.

Browsers are supposed to compile asm.js code directly into native code before running it. Running it through the VM is the fallback for browsers that don't support it directly.

I can compile BF directly to native code (and actually I did: http://blog.reverberate.org/2012/12/hello-jit-world-joy-of-s... ) so does that make BF native code? The point of these questions is that the GGP's statements are absurd. There is no universe in which asm.js is "native code".

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.

Re: On Asm.js

#158

Post by acjohnson55 »

jheriko wrote: post #150
acjohnson55 wrote: post #148

Earlier quoted context omitted.

The fact that asm.js is represented in text does not make it unlike assembly language. It makes it unlike bit/bytecode or machine code.

assembly is just mnemonics for the machine code - that is very important to remember. its a different encoding, but its one which has a strong and tightly coupled relationship to the point where disassemblers are a thing.. sure asm.js is encoded as text, but its not encoding anything close to what assembly languages do.

I have another reply to that effect somewhere in this thread :)

Modern assembly languages often at a slightly higher level of representation than 1-to-1 with the instruction set so it's tough to draw a tough line, but yes, generally speaking, you should be able to translate the majority of the language to machine code with opcode tables. It's also interesting that machine code isn't even the lowest level representation of machine instructions on many architectures, which internally use microcode to implement architectural instructions.

My point was that LLVM bitcode and asm.js are both intermediate targets, but not exactly the same.

Re: On Asm.js

#159

Post by acjohnson55 »

dirkk0 wrote: post #36
flohofwoe wrote: post #33

Earlier quoted context omitted.

You can but it's a bit like writing inline assembly code. The code doesn't look very nice and you lose LLVM's optimizer passes which kick in before the JS code generation.

But you could take Brython or Pythonium and make a Python2asmjs compiler (as I suggested in their forum: https://groups.google.com/forum/#!topic/brython/I7VoZNCiphI ) This could be a chance to skip JS altogether.

That's the great hope. Instead of bringing Javascript to the server side to have a single-language workflow, you'll be able to bring the non-JS language of your choice to the client side.

Re: On Asm.js

#160

Post by jheriko »

acjohnson55 wrote: post #158
jheriko wrote: post #150

Earlier quoted context omitted.

assembly is just mnemonics for the machine code - that is very important to remember. its a different encoding, but its one which has a strong and tightly coupled relationship to the point where disassemblers are a thing.. sure asm.js is encoded as text, but its not encoding anything close to what assembly languages do.

I have another reply to that effect somewhere in this thread :) Modern assembly languages often at a slightly higher level of representation than 1-to-1 with the instruction set so it's tough to draw a tough line, but yes, generally speaking, you should be able to translate the majority of the language to machine code with opcode tables. It's also interesting that machine code isn't even the lowest level representati…

You mean macro assembler languages? Its a pedantic distinction but I wasn't intending to imply those... 'Pure' assembly languages are still not 1 to 1 but are never worse than many to one, eg nop is often a real, but useless instruction with some other mnemonic....

Not sure what you point is about microcode... That is an implementation detail which, even for eg, x86 LEA where you think you are leveraging it, it is not important or useful beyond trying to understand performance characteristics. What you get to work with is whole instructions.

Post reply on HN