jor1k: OR1000 Javascript Emulator Running Linux
s-macke.github.io
s-macke.github.io
'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.'
I am working on it. But it is extremely unstable. In the picture you see the best shot I ever got.
Here's my list, please add to it if you know any others: https://gist.github.com/ysangkok/5606032
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...
Firefox 25.0a2 (2013-09-11)
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.
JavaScript... sigh
https://github.com/s-macke/jor1k/commit/1285da3247a1a92f6638...
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.
I've loaded it up and there's Monkey Island running on ScummVM running in a Linux VM running in Chrome's Javascript VM. Stunning.
1) I am waiting for a version using networking. I know there are security issues but there are also workarounds.
2) My notebook is hot, so I checked and the Chrome CPU console is at 25% even if I am not doing anything in the console.
Still, this is extremely cool, especially seeing an architecture from the OpenCores project being used.
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.
9P in Arm-js: https://github.com/ozaki-r/arm-js#emulator-features
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?
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.
# scummvmEven 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.
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!
e: these are just two things that were installed on my system despite not having software that needed them.
Ever since then, I've been unable to shake the feeling that something has gone catastrophically wrong with the way we architect software.
(My first machine with a proper multitasking, GUI based, OS was an Amiga where the OS with in a 256KB - later 512KB - ROM and two 880KB floppies)
But the impressive partbis the emulator itself... The emulator is a full SoC in javascript, based on the OpenRISC instruction set.
Edit - one oddity: on Chrome the console does not register the spacebar.
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.
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.
Read the lessons, follow along in another tab. No messing around with VMs etc.
How do you write so much JS code? (i.e. editor, testing, debugging, running, dev environment, etc.)
Thank you.
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.
Great work and very impressive.
Thanks!
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.
My scripts for the toolchain are published here: https://github.com/s-macke/jor1k-toolchain-builder
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.
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.
This work is giving a new mean to "impressive"