Slashdot Mirror
JavaScript-Based OpenRISC Emulator Can Run Linux, GCC, Wayland
An anonymous reader writes "The jor1k is an interesting open-source toy emulator project to emulate a 32-bit OpenRISC OR1000 processor, 63MB of RAM, ocfb frame-buffer, and ATA-hard drive ... all in JavaScript. Though JavaScript based, there are asm.js optimizations and the performance seems to be quite decent in modern web browsers. The jor1k OpenRISC emulator can do a lot, even handle running the Linux kernel, GCC compiler, ScummVM Monkey Island, and the Wayland/Weston compositor, all from within the web browser."
And the web browser runs on an OS, and so forth and so on.
Students still have too much time on their hands.
Je me souviens.
Running the demo in the Chrome browser on Linux pegged one of my 8 CPUs at 100% non-stop. Free memory stayed steady though.
Oh. I um. I guess it does.
So it's a virtual machine running on a virtual machine running on a virtual machine. Nice.
The opinions stated herein do not necessarily represent those of anybody at all. Deal with it.
THIS IS THE FUTURE!
(I heard you like Javascript and Linux, so I put a Linux inside your Javascript inside your Linux inside your Javascript inside your Linux.)
"The machine is big endian machine, but the typed array from Javascript work with little endian. "
I'm already not impressed.
Who cares about a hardware simulator running in a web browser?
I do.
Well, I guess everyone has read about the Javascript PC emulator :
http://bellard.org/jslinux/index.html
I wonder if this fad of porting everything to JavaScript has something to do with preparing for an imagined day when popular home computing platforms will become as locked down as iOS and the game consoles are today. Web applications run fine, but anything else requires the platform owner's digital signature. And for a long time, getting such a signature from console makers has required establishment of a corporation or LLC, the payment of a substantial entry fee, an additional computer for running the development environment, and a team of developers who have had to move hundreds of miles just to get the required "relevant industry experience" working for a well-known software company.
Remaking EVERYTHING in JS is a total, complete waste of time. There's a saying that everything that can be written in C will eventually be written in C. This makes sense because once it's in C, it's going to run really quickly. That little whatever that was re-written in C, even partially, is just about as good as it gets when it comes to responsive, low-overhead, user-space tools. JS will never get appreciably better than it is now without those improvements affecting all other dynamic languages in turn, and JS is not regarded as a mogul of excellent syntax, language features, or any of the other notable strengths of other languages. Anything written in JS will eventually need a re-write. Using Node for little async, concurrent server communication relatively a niche. Just stop. This JS nonsense is way out of hand.
There's a saying that everything that can be written in C will eventually be written in C. This makes sense because once it's in C, it's going to run really quickly.
Or not run at all if it doesn't get digitally signed. You often need permission from a platform's curator to use C on that platform. You don't need anyone's permission to use JavaScript.
News at 11.
Although TBH I like all these demonstrations of just how far we've regressed. "Remember doing this in the mid-'80s on an 8MHz 8086? Remember finding it a bit slow, then being so happy when you upgraded to that 286? Relive the original experience once again with feeling on a 2.6GHz desktop... in a browser window! And when the latest Fuckbuster Javascript engine is released, it'll be like a 286 again."
Therefore it can't be a real serious enterprise ready product.
Just ask any beancounter
http://saveie6.com/
That can change.
"Evil will always triumph because good is dumb." -- Dark Helmet
Would it change in the "more open" direction, with more platforms allowing use of unsigned native code? Or would it change in the "more closed" direction, with devices enforcing a no-script policy on web sites that haven't paid to be on the platform's whitelist?
Or not run at all if it doesn't get digitally signed.
Then you shouldn't be writing a emulator in JS. Not our fault if the system is a walled-garden. Plus I'd imagine that once this gets popular enough, EULAs and Developer Agreements will be rewritten to forbid it. If they don't already.
The greatest thing we have when it comes to IT is the ability to run what we (the owner of the physical device) want to, and the clueless and ignorant willingly hand over control in exchange for it being an appliance.
It will be a sad day indeed when the only way to run what you want is to ether build an "Illegal General Purpose computer system" or to bypass the special firewall on that compiler.......
Because they can.
Off topic, what happened to my slashdot, where this post would get modded down.. :(
We have a way to run Wayland apps inside a network-aware display app.
Have gnu, will travel.
I hate to say it, but in the world of end-user apps, Javascript won. (Note that I'm not talking about niche applications like 3D rendering or server software.) And I write this as a committed Mac and iOS developer. Moore's Law and improved JS compilers have made Javascript responsive enough for 99.9% of applications. Native end-user apps will stumble along for a while, but they're walking dead.
There are no more technological hurdles for Javascript to overcome. The payment model is the last nut to crack. Firefox is working on that. Maybe it'll take a bigger player to make it happen. But make no mistake: it will happen. It'll happen because it's cheaper to pay one development team that can deploy to every device.
As recently as last year, Facebook moved away from mobile to native, but that move already looks amazingly dated. Since Facebook moved from "HTML5" to native ObjC, Apple released the iPhone 5, which was over twice as fast as the 4s, and then the 5s, which is about twice as fast as the 5. The Javascript version of Facebook may have felt unresponsive on an iPhone 4 or 4S, but those days are history.
A lot of people may be reading this and thinking "yeah, yeah, people have been talking about 'write once, run anywhere' for decades." They're right—we've been staring at the oncoming freight train for decades, and now it's finally here. If you write end-user apps and you're not polishing your Javascript right now, that train will roll right over you.
You must have had an *awesome* 8 MHz 8086 if it could do this: http://www.unrealengine.com/html5/
and it's not a copy-paste of the Patterson & Hennessy books
http://yasep.org
It is even Mandelbrot-complete !
63MB of RAM?!
Get free satoshi (Bitcoin) and Dogecoins
Right, but it's only just gained keyboard support, so up until now it was a fairly boring text-demo.
"The true measure of a person is how they act when they know they won't get caught." - DSRilk
You are missing a major point. It's not just about being able to write a machine emulator in javascript, although that is a very impressive feat. Javascript has one major feature that no other language has: it runs natively, with no plugins required, in every modern Web browser. Javascript is realizing the dream that java aspired to: it runs on every modern computing platform.
As evidenced by the success of Google's Chromebooks, the Web browser is becoming, in and of itself, an operating system. There's a lot of old software out there that is still useful, but will never be rewritten. This kind of emulation might give some of that old software a new life.
I tried the demo on my Nexus 7 using Chrome. The OS boots up, but there doesn't seem to be any way to activate the on-screen keyboard, so no way to send input to the window. Still, very impressive that it (mostly) works on Windows AND Android!
The author of the bzip2 decompression code seems to have gotten a little bored writing the comments.
Good start. To polish this troll you need to write a bit more detail, making it more like you honestly believe this claim. It’s a good premise, and with a little work you could probably get a few hundred replies on Slashdot.
None of that was done by any Americans, but good old old-world Europeans.
I don't know about you, but I think USA is losing it.
The Javascript version of Facebook may have felt unresponsive on an iPhone 4 or 4S, but those days are history.
Nitpicking a bit - the JS engine used in Safari has seen much improvement in the past few years. But if you make a HTML5-based app with something like Cordova, it will use the old JS engine which is markedly slower. Sure, faster processor helps, but it would be nice if Apple would enable the newer JS engine on HTML5-based apps instead of just Safari.
This is WebGL, which is a wrapper round OpenGL, which is an API making use of...
It's almost like forbidding people to write books in Japanese because the good ones eventually get translated to English.
People do what they like. Deal with it.
Don't quote me on this.
The point here is that emscripten can get within 1/2 native speed when the resulting code is put on a modern JavaScript engine. You're not regressing 25 years; you're regressing about 18 months.
Oh goody, I can't wait. As an end-user of those applications, can I ask if there's anything else I can do to make your life as a developer any easier? Stop complaining about bugs? Buy a faster machine? Use a competitors application which isn't crap?
Ah yeah, maybe that last one!
Right, but that's not a technical issue; it's a policy issue. If people started buying web apps, there would be tremendous demand for Apple to turn on WebGL and JS optimization, and they'd do it.
You have it backwards—developers will hate the move to JS, and users won't notice. It's exactly the opposite of what you describe.
Developers won't do it willingly, but their clients and/or employers will demand it. It's strictly financial.
All developers should have to test their software in jor1k. If it runs too slow or consumes too much RAM the defects must be fixed prior to release.
From what I know, OpenRISC is an open sourced (I believe GPL'ed) MIPS CPU that exists in terms of HDL models, and can be implemented in any fab. So one could take the models, program it into an FPGA, and then one would have a functional OpenRISC CPU. What about a pure OpenRISC CPU? Well, get in the market & the volumes, and a company could start doing design and/or fabs, and you'd have a CPU. Given the costs incurred in designing it, the volumes have to be high enough to justify it.
So now they're simulating this CPU in JS? So is JS an HDL now? Or is it a case of a micro-simulator written in JavaScript and implemented on Windows? But what would be the point of doing that? Why not design an actual emulator of OpenRISC, have a VM of whatever OS one wants on it, and then build up all FOSS apps for that?
Port a game like gears 3 over to emscripten and see how it does. Citadel has 0 code other than graphics and texture loading going on. Run the ai and all the rest of a real game engine in it at a reasonable rate and I might start getting impressed.
Oh STFU. If you come out with a neat piece of software that runs in a browser, you can post a link to it (like this one) and millions of people can run it in a single click because it's so damn easy. If your software is written in anything else but JavaScript, people have to screw around downloading runtimes and saving and executing binaries, and at best 5% as many people will bother trying it. Sure, an app store simplifies that, but now you have to build multiple app versions, iOS, Android, and whatever the hell Windows uses, and you've still left millions of potential users out.
It's the universal availability of JavaScript and zero-install that you get by running it in a web browser that drives the innovation and interest in it, and there's no sign of it stopping. Go build an OpenRISC emulator in C that's far better in every way than this, post a link to the installer, and watch your effort get ignored.
=S
It does fit nicely into the "neat" and "cool" categories.
I have zero use for it, but it is still neat and cool.
Kudos to the coder.
This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
It would run fine... Game engines are just not that CPU intensive, and JS can do a few megaflops on low end hardware. The reason no one has done a game that elaborate in JS is that there's no way to charge for it.
sure, on the day that webpages either stop using js for everything OR the machine in question becomes so locked up that you can't browse the web with it.
world was created 5 seconds before this post as it is.
Under the name of Atomic OS, I've been playing around with related ideas (on and off) for nearly a decade now.
Although I have a number of others, my primary suggestion would be to add WebRTC-based network devices in jor1k or JS/Linux. This would allow SPAs (Single Page Applications) to provide an interface into new censorship-resistant networks.
Yes it's putting tubes in your tubes but I think it'll happen and likely sooner than you think. There's at least one project out there (name withheld by request of the projects' author, will go into beta soon) that I suspect will usher in a new era of web-based computing.