implements the Fibonacci series in two machine instructions (notice eax and edx have 514229, 832040 in them after you run the example, the 29th and 30th Fibonacci numbers). I first saw that in a book a friend got me for christmas; a hard copy of this site: https://www.xorpd.net/pages/xchg_rax/snip_00.html
I'm glad someone caught the reference. Indeed, I took it from the [xchg rax,rax] book.
Also, I have to apologize for the many bugs the demos have at the moment (annoying editor, missing features), I intended to post a Shown HN post at a later point in time. During the next days I will be taking care of these matters. By the way, these demos rely in Capstone.js/Keystone.js to assemble/disassemble machine code (if anyone is interested, similar demos can be found at https://phi.nz/).
i wonder how performance of this (emscripten of Unicorn) compares with this much more flexible ARM emulator from a few years ago (which I am much more excited to use for things as I can easily customize the instruction fetch and memory access routines; it is even straightforward how to just hook system calls).
Probably that Arm-js emulator you mention is faster: Unicorn is based on QEMU, which internally does the translation by translating the guest machine code to an IR. After optimizing it, this IR usually gets compiled back to the host machine code, but thanks to the TCI [1] the IR can be directly interpreted anywhere without the need of a compiler backend. All these steps incur on an additional overhead that wouldn't be there if one interpreted ARM code directly.
You say "you" multiple times, but I did not implement this other emulator: I simply found it yesterday while evaluating options for emulating armv7 on top of JavaScriptCore.
On the other side: this CPU emulator is written using high-level JavaScript, and I think some of its control flow is implemented using exception handling, whereas compiling Unicorn to asm.js will get reconstituted in modern broswers back to reasonable native code (and qemu is designed to be fast). I don't think it is clear cut which is faster.
(I would do a benchmark, but for my use case I actually am working with interpreted JS, which is massively different, and I had already evaluated that Unicorn.js wasn't flexible enough for my intent, so it is more of a curiosity than a question I would spend time to answer myself.)
My bad, I realized my mistake and was editing my message right before your answer.
Indeed, performance is not clear and probably depends a lot on the browser's JavaScript engine. I will try to find that out in the future with some benchmark.
In case by "find" you mean "where are SPARCs still being used"... It is something of a niche, but all our missions in the European Space Agency use LEON processors; a design based on SPARC [1].
And since you mentioned OSes, usually it is either bare-metal stuff or RTEMS [2].
Ebay "SPARCstation"? Shipping tends to be expensive as they are heavy, and you need to make sure you get a complete system. You can probably find a version of Netbsd or OpenBSD that boots and has source, from which you can reverse-engineer the startup.
Some of Netgear's ReadyNAS devices had (slow by today's standards) SPARC chips in them[1]; I have a ReadyNAS Duo with a SPARC chip in it. They also have a Debian-based OS for SPARC.
I picked up an old UltraSPARC Sun server a while back for $10. Never got it running as I didn't understand serial connections and it was annoyingly loud.
> With all that said, QEMU is an awesome project, which Unicorn was born from. However, Unicorn is not just QEMU, but offering a lot more because it has been designed & implemented especially for CPU emulation.
Couldn't they extend Qemu, or there was a reason for making a separate project?
