
Unicorn: lightweight, multi-platform, multi-architecture CPU emulator framework - signa11
https://www.unicorn-engine.org/
======
pg_bot
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...](https://en.wikipedia.org/wiki/List_of_legendary_creatures_by_type)

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

~~~
lstodd
Why didn't they name it Multicorn?

~~~
empaone
That name is also taken:

[https://multicorn.org/](https://multicorn.org/)

~~~
johnhenry
Disappointing that their logo is just a unicorn. :/

------
monocasa
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.

~~~
muizelaar
V8 wasn't originally based on llvm. If anything, it was based on Strongtalk.
[https://github.com/v8/v8/commit/43d26ecc3563a46f62a022403066...](https://github.com/v8/v8/commit/43d26ecc3563a46f62a0224030667c8f8f3f6ceb)

~~~
monocasa
Oh, my bad, misremembered.

~~~
munificent
You may be thinking of Rubinius?

~~~
monocasa
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".

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

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

~~~
MerryMage
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](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.

~~~
pm215
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...](https://git.linaro.org/people/peter.maydell/risu.git/tree/README)

(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.)

~~~
MerryMage
> 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/...](https://github.com/MerryMage/dynarmic/blob/master/tests/A64/fuzz_with_unicorn.cpp).
This uses our instruction table
([https://github.com/MerryMage/dynarmic/blob/master/src/fronte...](https://github.com/MerryMage/dynarmic/blob/master/src/frontend/A64/decoder/a64.inc))
to generate instructions.

------
mnafees
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.

~~~
learc83
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.

------
EamonnMR
QEMU supports PowerPC, but this appears not to.

~~~
cestith
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.

~~~
nickpsecurity
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.

------
sdegutis
Github link was kinda hard to find: [https://github.com/unicorn-
engine/unicorn](https://github.com/unicorn-engine/unicorn)

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

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

------
sam0x17
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.

------
sergiotapia
Thought this was related to the unicorn app server.

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

Change the name my dude

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

Edit: Looks like they are based on QEMU.

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

------
robbywashere_
Is this able to run on webasm?

