Unicorn: lightweight, multi-platform, multi-architecture CPU emulator framework | Hacker News Reader

Unicorn: lightweight, multi-platform, multi-architecture CPU emulator framework

unicorn-engine.org

181 pointssigna1141 comments

So many projects use the name "unicorn", that I think we should declare a moratorium on its usage. There are plenty of mythological creatures to go around.[0] If you feel the need for your project to be 'corny' may I suggest naming it after the bicorn[1], which has double the horns and is therefore twice as interesting.

[0]: https://en.wikipedia.org/wiki/List_of_legendary_creatures_by...

[1]: https://en.wikipedia.org/wiki/Bicorn_and_Chichevache

Why didn't they name it Multicorn?

That would be a pretty good name. Has the added benefit of sounding like multicore. Other alternatives I can think of are cpucorn or even silicorn.

> silicorn

Trademark that, it's awesome

That name is also taken:

https://multicorn.org/

Disappointing that their logo is just a unicorn. :/

Personally, I'm a fan of Polycorn

https://youtu.be/a9GoWGnFzGA?t=16

(I cannot resist making a They Might be Giants reference.)

There's precdent for "Omnicorn" [1]-- after all, "On its head is every manner of horn".

[1] http://tmbw.net/wiki/Lyrics:Omnicorn

I understand that naming conflicts make things harder to search for, but I don't like the notion of a 'we' saying how things can be named. People should be free to name their projects how they see fit and whatever connects with them. A person would likely need to search for 'unicorn emulator' anyways and it comes right up.

Obviously you are free to name your project whatever you like, but I think it is important to avoid clichés. Part of fixing any problem is pointing out its existence. If I could actually dictate rules, I would start by barring music video directors from including any audio that is not in the single from their work.

> People should be free to name their projects

And free to comment on them, hopefully politely.

The "we" that is implied holds no power over what someone names something, so it doesn't really matter anyway.

Good news: pg_bot is not the king of the universe and this is just a suggestion in a post instead of an official decree.

We should instead have a moratorium here on HN against comments complaining about how projects are named. They distract us from useful discussions about the project itself.

It's the core of qemu, refactored out to something that's usable by other clients.

For emulators it's great for getttig started and prototyping, but if you care about perf you end up migrating to a more integrated solution. Sort of like how V8 was originally based on llvm, but wrote their own backend.

V8 wasn't originally based on llvm. If anything, it was based on Strongtalk. https://github.com/v8/v8/commit/43d26ecc3563a46f62a022403066...

Oh, my bad, misremembered.

You may be thinking of Rubinius?

Nah, I was thinking of JavaScriptCore. They replaced their last tier JIT a few years back; it used to be LLVM, but now it's a custom backend "B3".

How can you improve perf if you have a guest OS/program running on SPARC and your host is x86? Maybe I’m not understanding it correctly, but don’t you have to translate all the registers and instructions from SPARC to x86? How would you run SPARC code natively on x86?

V8 the JavaScript runtime, not SPARC V8. It turns out I was wrong about that part too.

The Nintendo Switch emulator `yuzu` started out using this, but has been gradually moving to https://github.com/MerryMage/dynarmic instead.

Is there more context on why they're switching / how they gradually move over? I'm very interested.

I don't know about switch emulation, but I know there was an Xbox emulation project that wanted to use it, and gave up. The reason was that Unicorn doesn't have paging working properly on x86. In refactoring Unicorn out of Qemu, it somehow got messed up, and as a result Unicorn isn't useful for full system 32 bit x86 yet. The Github issue is here: https://github.com/unicorn-engine/unicorn/issues/947

Perhaps it is better for other guest processors, but for x86 Unicorn still needs time to mature and get some critical problems fixed.

Hey, author of dynarmic here.

> more context on why they're switching

I started working on an AArch64 (ARMv8) frontend for dynarmic upon request from yuzu's developers. At the time, they decided to switch over because dynarmic has better performance compared to unicorn.

To be honest, I feel like unicorn has instrumentation as a primary goal. Dynarmic has different goals: (a) performance and (b) ease of integration into pre-existing/custom emulated memory systems.

When I last looked at unicorn it didn't quite have a full ARMv8 implementation; yuzu maintains a fork of unicorn that follows upstream qemu more closely at https://github.com/yuzu-emu/unicorn. We use this version of unicorn to test dynarmic by fuzzing the emulators against each other to ensure accuracy of emulation.

> how they gradually move over

Dynarmic has "fallback" capability -- if an instruction isn't implemented, a user-provided callback is called so the library user can provide an implementation of the unimplemented instruction. yuzu uses unicorn as the fallback implementation. This was helpful for getting the system up and running in the early days.

We're not quite at full ARMv8 support yet (we're at about 70% --- half-precision floating point support and ARM pointer authentication are the biggest unimplemented features), but the vast majority of guest applications in yuzu do not currently fallback to unicorn.

QEMU hasn't got round to pointer-authentication yet either, so that's pretty good going.

I like the "fuzz-test one implementation against another" approach. That's quite similar to how we test QEMU against real hardware (at least for straightforward userspace insns): https://git.linaro.org/people/peter.maydell/risu.git/tree/RE...

(Upstream in QEMU we're talking/working on trying to improve our support for instrumentation. But definitely today we don't do anything much in that area.)

> QEMU hasn't got round to pointer-authentication yet either, so that's pretty good going.

Thanks very much! I do however note we're not trying for full system emulation for v8; we're primarily interested in userspace emulation since that's our primary usecase, so system instructions aren't necessary for us, which does reduce our workload!

While we're on that topic, we make a few simplifying assumptions for performance reasons (e.g. no self-modifying code). Thinking about it, I feel like I should document these assumptions somewhere; I'll do that when I can.

> That's quite similar to how we test QEMU against real hardware

That's great! I love semi-automated testing.

An emulator vs emulator fuzz test has some advantages: You can test more instructions than you are able to on hardware. For example, you can test arbitrary jump instructions and memory instructions (assuming the emulations have sufficient instrumentation to catch arbitrary memory reads/writes and jumps off into the ether).

We fuzz against unicorn here: https://github.com/MerryMage/dynarmic/blob/master/tests/A64/.... This uses our instruction table (https://github.com/MerryMage/dynarmic/blob/master/src/fronte...) to generate instructions.

This is so cool! Especially for us university students who are taught MIPS in our compilers course, it will be cool to use this to re-create the emulator our University uses to run our MIPS ASM code.

I remember we did SPARC assembly in college and the only way to test your program was to ssh into a single ancient SPARC server.

I actually started building an emulator because I thought it might be easier than dealing with that workflow. One sleepless weekend later it turned out I was very wrong.

QEMU supports PowerPC, but this appears not to.

It seems from the changelog that it compiles and runs on PowerPC but that it won't emulate PowerPC. That seems a bit odd to me in itself. It's extra odd that they aren't supporting something the trunk project does which is still fairly widely used.

I was wondering about that since safety-critical still uses lots of PPC products like Freescale's. Industry folks probably have boards to work with. Hobbyists or small businesses trying to get in the game might need Qemu or something to experiment on good, x86 boxes. I kept a Mac PPC for it, too, but they'll diverge due to age.

So, PPC support was one one of first considerations looking at Unicorn. Thanks for posting that it's partly there.

Github link was kinda hard to find: https://github.com/unicorn-engine/unicorn

Download->git repository (from the link posted here..) wasn't that hard to find.

There’s a Github icon in the bottom of the page (together with the email and Twitter accounts)

Oh I just assumed Download linked straight to a zip file or something so I instinctively skipped over it.

If my understanding is correct, this would be great for people who are stuck in non-root situations and need to run something (very prevalent in DoD and enterprise / large school situations). Hopefully they package it in a way that can run without root, as that was always my main application for QEMU.

Thought this was related to the unicorn app server.

https://en.wikipedia.org/wiki/Unicorn_(web_server)

Change the name my dude

It’s cool that they support SPARC and a wide variety of other architectures.

Edit: Looks like they are based on QEMU.

I used this. It’s really rough around the edges but if you use it correctly it works brilliantly.

Is this able to run on webasm?

Reply on news.ycombinator.com