'In the beginning google Chrome was the fastest. After more and more optimizations were implemented Firefox was little bit faster then Google Chrome. When IE10 became compatible with my code it was the fastest. After implementing the worker thread Firefox 22 got superior being 3 times faster then the other browsers. For some reason this advantage got lost with Firefox 23. Instead of this Google Chrome managed with version 29 to get this position with 30-50 MIPS. At this moment changing one line of code in the Step() function could reduce or increase the speed by a factor of 3. The reason for these speed oscillations is the tremendous complexity of todays JIT compilers and the black box behavior of them which makes it almost impossible to code really fast code.'
Sadly, the choice of OpenRISC also means it's hard to get Xorg working, since it wasn't tested on OpenRISC. Also, the gcc OpenRISC target has a number of bugs, I've heard.
Arm-js has a control panel which is really nice. It would be sweet if the open-source emulators could share some code, but they are pretty different code-wise right now...
EDIT: Interestingly in Chrome Canary it starts out running at around 50 MIPS and then at some point v8's jit recompiles/deopts some code and it drops down to 12 MIPS and stays there.
Oh wow, you wrote it all by hand? That's really impressive! :)
If the standalone asm.js validator isn't yelling about that and Firefox 25 is, you should let the people who maintain the validator know. They're supposed to be in sync.
Yes, programmed the asm.js core by hand. It was not too hard. One day. The asm.js is also a little bit outdated. It could be around 20% faster. I have never used the standalone asm.js validator. Not even knew, that it exists.
The optimizing work in Javascript is really hard. Every few weeks there is a new browser and new mystic speed issues.
Firefox 22 without asm.js was the fastest six weeks ago (30-60 MIPS). Then everything changed. And I don't know why. Even the IE is faster than Firefox (without asm.js) right now.
Very impressive work. I saw Brendan Eich speak At jquery uk in April and he said asm.js was meant for compilers and people should not be programming it directly...I couldn't help but smile and think 'oh yeah?'
Yeah, I've had the same experience. I applaud your persistence! Hopefully asm.js will eventually let you avoid babysitting your code with every browser release.
The greatest potential is ofcourse having a cloud service where people can store their disc and hibernated emulated RAM and then switching to another browser on another machine and continue working like nothing happened.
I'd have to look at the code, but it might not be too awful to get tun/tap to work over WebSockets...
Regarding the heat, I wonder if the architecture has support for idle states. If so, the VM should "clock down" by executing its loop from a timer instead of full-bore. I wonder if this is already happening, though.
I tried adding an extra serial port some months ago, but I didn't succeed.
It would be really cool if you made this. Here's a use case I had in mind:
You go to emulator.html#http://otherwebsite.com/packages.json . The emulator's JavaScript part detects the fragment, and downloads a list of dpkg packages to the HTML5 file system. The emulator boots up, checks the HTML5 file system over 9P, and installs all those packages.
Like this, you could test any binary package over the web without fear, and it would be decentralized, you wouldn't have to modify the emulator.
But for jor1k, we'd need networking and 9P/HTML5 support (like in Arm-js). For Arm-js, just the networking would suffice, as the 9P support is already there.
Saw that issue, hope to eventually respond to it with a pull request.
Are you Sebastian Macke? [Edit: scratch that, I see he's commented elsewhere.] Either way, get in touch (info in my profile). I'm curious to hear what issues you ran into in trying to add another serial port. I'm not terribly familiar (read: not at all familiar) with OpenRISC, but I'd imagine it's just a matter of creating a second instance of UARTdev in system.js and adding it to the 'ram' object at an appropriate base address. If OpenRISC is similar to ARM, you may need to add the second uart to your platform/chip/board init as well so the system is aware of it.
Regarding networking, I intend to actually implement eth.js and wire it to a WebSocket, then on the other end I'll write a receiver which hands the frames to/polls a TAP device. At that point, you can do whatever you want on the backend with that interface. I'd like to start this weekend, but (how often does one get to say this?) I'll be at the governor's mansion and that's going to take a bunch of my time.
I'm not sure I follow on the package management bit. Would these be emulator extensions, or packages which the image would use?
This features sound like fun. But networking is not on my priority list right now.
Problem is the server and security issues. At the moment everything runs out of the box even on the simplest web server. This would change. And at the moment I don't want to implement features which you can't use on the demo web-site.
But of course, you are free to do so. You have not even to change something in the kernel-image because everything is ready to test. Exchange the dummy ethernet driver with the real one from the or1ksim project.
I think the main issue is that the console and framebuffer use canvas elements which are continuously refreshed by a javascript timeout. This tends to use up all of a single core, no matter how little of the screen is actually changed. Perhaps using requestAnimationFrame could improve the CPU utilization.
As written in the wiki, Firefox 23 is at the moment not a good choice. Firefox 22 emulates this machine three times faster and possibly Firefox 24 will return to this peak. Chrome is fine.
Go back to the late 80s/early 90s and small System 7 UNIX clones like Mark Williams Company's Coherent 3.2 could install, complete with their entire userland, dev sys, docs, and formatters in around 10Mb of disk space and run on a 286 with 640Kb of RAM. No TCP/IP stack (it used UUCP for comms) and no X11, but if you fast-forward to 1992 you could have Coherent 4, with TCP/IP and X11, running on a 386 with 4Mb of RAM and installed in 20Mb of disk.
Even the mammoth (by the standards of the day) SCO Open Desktop 3.0, with X11/Motif and a bagload of other stuff, could install in less than 200Mb of disk space and run reasonably smoothly on a 386/33 with 16Mb of RAM. That was a full-blown workstation grade UNIX distribution with all the trimmings. These days word processors are bigger.
Back in the day, you could boot the entire BeOS kernel, filesystem, GUI, network stack, window & task manager, and web browser off of a 1.44mb floppy disk.
Ever since then, I've been unable to shake the feeling that something has gone catastrophically wrong with the way we architect software.
I'm seriously considering switching to using an AmigaOS mail client + UAE (Amiga emulator) instead of Thunderbird because of how slow and bloated it is - there are at least two AmigaOS mail clients still in development, and given that they are written to still be able to run on the old m68k Amiga's (in addition to on newer PPC systems) I have an inkling they'd come out of it quite well.
Well when you add up all the backdoors to the various spy agencies worldwide, plus the obfoscation mass code, I the that accounts for the bloat. good luck finding it amongst the 18 GB sources of Android, or similar for the other systems.
We expect more out of our software, so we write more code to do it, and we complain about bloat because no individual person uses, or expects to use, every feature in every piece of software. However, when anyone comes along to remove features, people complain even worse because, of course, nobody can agree about which features to axe! Everyone is using different subsets!
And that "bloat" also comes from features in libraries that the developers use. It's much of what allows development to happen at a much more rapid rate than it did in the past.
I am using firefox 23.0, the program appears stuck at the decompressing step while showing 0 MIPS. Also restart with asm.js button doesn't appear to work.
That's less an issue of running native code (you can do that with asm.js or emscripten), and more an issue of the numerous additional platform APIs provided in NaCl that HTML5 doesn't have: USB, Bluetooth, GLES...
In general a JavaScript-based Linux virtual machine should allow you to run software that would otherwise be difficult or impossible to run in the browser (which right now can be done for a lot of software by compiling it to JavaScript with https://github.com/kripken/emscripten). Data could be transferred to the VM for processing and then back to "normal" JavaScript using serial I/O. This might prove a useful kludge.
For a simple example of where it could be used consider a webmail provider who wants to get GPG encryption into their web UI. The provider could embed a Linux VM in the HTML document to let the user do encryption with the well-examined native version of GPG. (Although native GPG running inside this VM would not be safe from, e.g., malicious JS in banner ads.)
Right now the emulation is too slow to do these kinds of things practically, however, and it's hard to say whether or not it will get sufficiently fast before other tools for running native software the browser fully mature.
tptacek tells me that secure JS is never going to happen so I don't see a use case there. Yes, proof of concept is cool, until someone steals your private key. No thanks.
I suppose though you could non-secure stuff, like add a Python interpreter or C compiler and teach people to code inside the VM. GitHub could provide in-browser syntax checking using a real interpreter/compiler.
Editor: Normal text editor with syntax highlightning
Testing: Firefox and Chrome
Debugging: Function console.log
Optimization: JIT inspector for Firefox (incompatible since FF 23) and profiling tools from both browsers
So, nothing special involved. Neglecting the redundancy, the source code contains 4000 lines of code. The complicated part was the building of the Linux image and libraries with a toolchain in beta status.
Curious to know more about the toolchain bit. Have you messed around with getting it to work with OpenEmbedded or Poky?
Also please do feel free to contact me out of band (info in profile). I'd like to implement ethernet support, but if you're halfway through I'd hate to duplicate your effort.
Unfortunately the scripts are broken but show the overall complexity to build the linux image.
The ethernet device in jor1k is a dummy right now but the kernel is already prepared to work with this device.
So everything I have to do is implementing the correct device which is defined here:
https://github.com/openrisc/or1ksim/blob/or32-master/periphe...
But nothing has been done right now. It is not my main priority right now because it would need a server script. And github does not allow this. And there could be a lot of security issues as well if I would add this to a demo.
Thanks. I've seen eth.js and was just waiting for OpenCores to approve my membership so that I could start working on it. I didn't realize the spec was on github.
I need to look a bit more at how everything is laid together, but my intention is to have eth.js write ethernet frames to a WebSocket, then on the server side read/write frames from/to a TAP device.
As for the demo, there's no reason why you can't just turn off the socket for the static demo. Otherwise, I'm intending to host something on DigitalOcean to prove it works. I'm sure whatever it is it will be very simple so I don't wind up with a huge bandwidth bill, but I'm hoping I can think of something that's clever and easy on the wallet. Maybe I'll make it add all machines to one giant subnet or something... we'll see.
Problem is almost nobody writes JavaScript which doesn't manipulate the DOM in some way, so you almost always need to test in-browser. Otherwise, there's no reason why you couldn't write automated tests to exercise most of this in a headless v8. Won't be good for profiling, but it will at least be good for validation/regressions.
Yes, I thought about it. The DOM manipulation and the hardware emulation is separated. Unfortunately with the implementation of worker threads it became more complicated to run this code in headless v8.
'In the beginning google Chrome was the fastest. After more and more optimizations were implemented Firefox was little bit faster then Google Chrome. When IE10 became compatible with my code it was the fastest. After implementing the worker thread Firefox 22 got superior being 3 times faster then the other browsers. For some reason this advantage got lost with Firefox 23. Instead of this Google Chrome managed with version 29 to get this position with 30-50 MIPS. At this moment changing one line of code in the Step() function could reduce or increase the speed by a factor of 3. The reason for these speed oscillations is the tremendous complexity of todays JIT compilers and the black box behavior of them which makes it almost impossible to code really fast code.'