10 ms·

This is demonstrative of the advantages of the new low-level APIs being added to JavaScript to work efficiently with binary data. Fabrice uses this to implemen

• euroclydon 15y ago
  Can you explain the steps necessary to combine a JS x86 interpreter with a binary Linux disk image into a running VM? The part I don't understand is, what environment does the Kernel need to think is there, and how is that done in JS?
  • cakeface 15y ago
    This is explained well in the Technical Notes section of the site. http://bellard.org/jslinux/tech.html http://bellard.org/jslinux/tech.html
    • euroclydon 15y ago
      I saw that, but I don't understand how it's booted.
      • nupark2 15y ago
        From what I can see from the minimized JS, it: - Loads the linux binary and the root memory disk image into 'memory' at the expected addresses (0x100000 and 0x400000, respectively) - Sets the interpreted x86 CPU's EIP to the kernel's entry point - Initializes additional requisite register state - Starts execution. Take a look at load_binary() and start() functions. [edit] rickard already discussed this here: http://news.ycombinator.com/item?id=2555552 http://news.ycombinator.com/item?id=2555552
• qbg 15y ago
  In theory, someone could create a common bytecode as a library. Such a library would probably use the Relooper algorithm from Emscripten (https://github.com/kripken/emscripten https://github.com/kripken/emscripten) and JIT the bytecode to Javascript that can then be eval'd for near Javascript-level speed.
  • chc 15y ago
    The whole idea is to get better performance than current JavaScript interpreters allow. Making something slower than JavaScript is the opposite of why people want a common bytecode.
    • memvov 15y ago
      It can be implemented first on Emscripten to see if people like it; later it can be standardized.
• powertower 15y ago
  >This is why so many people want to see the browser execution environment offer more complete, low-level APIs instead of high-level APIs locked to HTML/CSS and legacy browser technology. It's called the desktop and offers all the native and low-level stuff you can possibly imagine. And the only people that want to see it, are the ones who have forgotten about it. Maybe there is a middle ground between desktop software and browsers, but personally I'd like to keep them apart.
  • nupark2 15y ago
    > It's called the desktop and offers all the native and low-level stuff you can possibly imagine. Actually, I'd say it's called 'mobile'; The desktop failed to solve the sandboxing problem. > And the only people that want to see it, are the ones who have forgotten about it. As a desktop-turned-mobile developer, I haven't forgotten anything. Simply put, I want a future in which we aren't forced to re-implement our applications multiple times for disparate, proprietary mobile platforms. I already lived through that on the desktop. The only reason I haven't embraced the web for application development is that the technology stack is, by comparison, hobbled. > Maybe there is a middle ground between desktop software and browsers, but personally I'd like to keep them apart. Treating the browser as the sacrosanct temple of HTML, CSS, and JavaScript is throwing away the limited opportunity browsers have to pre-empt Android and iOS as a first-class, standardized application platform.
    • podperson 15y ago
      I'd love to see something replace HTML, CSS, and JavaScript, but how would this be different from Java? We already have Java.
      • mythz 15y ago
        >> but how would this be different from Java? It wouldn't suck.
        • podperson 15y ago
• azakai 15y ago
  I agree that for CPU emulation, something low-level like typed arrays is absolutely necessary. However, with more high-level code, in general there shouldn't be such a need. For example, RPython is very high-level, but is compiled into very efficient C. The same could be done for JavaScript (and to some degree already is).
• tlrobinson 15y ago
  Imagine what kind of advances could be made if a common bytecode was established I'm beginning to believe NativeClient and PNaCl (LLVM on NaCl: http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf) has the best shot at becoming this. Google is already including NaCl in Chrome developer builds, so I wouldn't be surprised if they enabled it in releases by the end of the year, and started releasing Native Client applications soon after. http://blog.chromium.org/2011/02/native-client-getting-ready-for-takeoff.html http://blog.chromium.org/2011/02/native-client-getting-ready...
  • nupark2 15y ago
    > I'm beginning to believe NativeClient and PNaCl has the best shot at becoming this. Me too, although the biggest hurdles seem as much political as they are technical. My hope is that Google can strong-arm NativeClient into active use, forcing otherwise recalcitrant browser makers (Mozilla, Apple, Microsoft) into adopting it.
  • jonknee 15y ago
    NativeClient is being distributed in the official public build of Chrome, just in a disabled state. You can turn it on in about:flags.
  • tectonic 15y ago
    I don't know a lot about NaCl but my gut reaction is that it will be insecure and allow my computer to be remotely exploited. Why am I wrong?
    • nupark2 15y ago
      http://www.chromium.org/nativeclient/reference/research-papers http://www.chromium.org/nativeclient/reference/research-pape... It's possible that the design could be flawed, but the same is true for browser implementations and mobile application sandboxing.
    • tlrobinson 15y ago
      The entire point of NaCl is to run native code securely. I won't get into the details because there's tons of information out there (http://www.chromium.org/nativeclient/reference/research-papers http://www.chromium.org/nativeclient/reference/research-pape...), but code must be compiled using a special NaCl compiler, then before it's executed the client runs it through the NaCl verifier to ensure it's safe to execute. Of course it's possible there are bugs in NaCl, but Google won't enable it in Chrome by default until they're very confident it's secure.
• guygurari 15y ago
  Exactly. I never understood why the web community decided to re-invent this wheel. We started with a model for text publishing (HTML), and are trying to evolve it to allow full blown apps. If browsers simply supported the JVM as the browser execution environment, instead of implementing their own javascript engines, we'd have: 1. More language independence 2. Great performance for games, video (think implementing codecs without the need for browser support), and for crazy things like this. 3. Most importantly, the ability to run actual desktop-like apps in the browser at near-native speeds, instead of the mess that is currently required to get web apps to behave like desktop apps. (Nowadays Rails and friends are hiding most of this mess, but it's still there.)
  • mythz 15y ago
    Have you never used Java Applets? (i.e. JVM in the browser) the load time alone makes that a terrible idea. Not too mention the 'breaking the web/page model' and poor UX that ensued. Strange that people actually think Java would be the saviour. Feel free to keep continue to use Java applets if you think they're superior tech, they should still be well supported.
    • rbranson 15y ago
      While I don't think the JVM is the savior, applets are a far cry from a good example. Applets usually cause the browser to lazy load the entire JVM as a plug-in, from scratch. Very little effort has been put forth to make this process fast. It's likely if the JVM was directly integrated, it would remain resident.
    • guygurari 15y ago
      I have used and written applets, and they are horrible, but it's not what I'm suggesting. Applets run in their own area on the page and can't interact with the rest of the page like javascript does. I'm suggesting to replace the javascript runtime with a JVM runtime, while supporting everything javascript does through an API. Here's the use case I'm imagining: 1. When a user starts loading a page (read 'web app') the browser spawns a new JVM for that page. How long does this take? You can bring it down to the price of a fork if you keep a JVM running at all times. 2. Instead of running javascript that's embedded in the page, you compile and run Java/JRuby/Jython. Better yet -- have the server precompile the embedded code and send you the bytecode. Load it dynamically into the JVM and run it in the page's thread. With a modern JVM you get JIT for free and the code runs at near-native speeds. 3. Want long-running background tasks? No problem -- the JVM code can start its own threads. Suddenly AJAX, and all the other stuff we use to make web apps behave like desktop apps becomes trivial. 4. User leaves the page / web app? Kill the JVM.
• dkersten 15y ago
  I've always wished that, instead of a "browser language", browsers exposed a LOW LEVEL bytecode environment (which browsers are then free to interpret, JIT compile or on-the-fly AOT compile at page load time). It should be reasonably low level, in that it should provide an abstraction from the hardware, but still allow for very efficient execution of lower level code. Then high level languages and frameworks could be layered on top. This way, browser languages would be 1) more efficient if they need to be and 2) more diverse. Its a pity that javascript is so in-grained in client-side web now, as its really a terrible bytecode... Hell, failing the above, I would have liked to see Lua as the default client-side language, rather than Javascript (for reasons I will mention shortly), but of course that will never happen now that Javascript has been the default for fifteen years. The reasons I would like Lua as the default language, besides the fact that LuaJIT is very fast (certainly for number crunching code, especially if you use the FFI to operate on low level structs (I mean, without calling into C) - the FFI is also one of, if not the, simplest FFI I've seen in any language[1]), it is, at least under my impression, a much more consistent language, while being just as flexible, easy to learn and dynamic. The thing I dislike most about Javascript is that it has lots of little gotchas and inconsistencies. Having said that, though, perhaps Lua does too and I just haven't used it enough yet to get bitten by them. Then again, it didn't take long for this to happen in Javascript, so Lua does at least seem to be a little friendlier. [1] Actually, I think Factor's FFI is similarly simple, if my memory serves me correctly
  • copper 15y ago
    Factor, Racket, and Lua all have ffi's that are very easy to use. I've never quite liked Lua's metaprogramming, though (macros are very useful when you're writing bindings.) and my least favourite Lua quirk would be the lack of integer types - both other languages have fairly sane (and performant!) numeric towers. That said, I'd give a higher priority for the language in my browser to be safe: some kind of correctness guarantee would be nice. Or even, while we're at it, some kind of way to analyze the script and say "this script GETS from urls x,y, and posts data d to z"
    • dkersten 15y ago
      Standard Lua may not have integer types, but as far as I know, LuaJIT does actually support integer types under the hood. At the very least, you can force it by declaring an integer using the FFI, eg: local ffi = require("ffi") int = ffi.new("int") int = 10 print(int) I also don't find the lack of macros in Lua as limiting as I do in other languages. For example, if I wanted to create an EDSL in Lua, I would have it parse a string at startup. For example, imagine a state machine DSL: fsm = my_dsl[[ start: foo stop: quux foo -> bar foo -> baz bar -> foo baz -> quux ]]{ foo = function() code for foo here end, bar = function() code for bar here end, baz = function() code for baz here end, quux = function() code for quux here end } fsm.run() As a real-world example, here is some Lua code I'm using in a hobby game project: DEFINE(Traits.Position)[[ float x; float y; float z; ]] DEFINE(Traits.Movement)[[ float x; float y; float z; ]] DEFINE(Behaviors.do_movement){ input={Traits.Position, Traits.Movement}, output=Traits.Position, frequency=0.01, -- Update entities position fn = function (pos, mov) local delta = dark.timedelta new_pos = Traits.Position.new() new_pos.x = pos.x + (mov.x * delta) new_pos.y = pos.y + (mov.y * delta) new_pos.z = pos.z + (mov.z * delta) return new_pos end} -- Create a sample entity local entity = Entities.new() entity.add(Traits.Position, {1.0, 0.0, 0.0}) entity.add(Traits.Movement, {0.0, -1.0, 0.0}) "That said, I'd give a higher priority for the language in my browser to be safe: some kind of correctness guarantee would be nice. Or even, while we're at it, some kind of way to analyze the script and say "this script GETS from urls x,y, and posts data d to z"" I definitely agree with the above.