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.
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.
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.
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.
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?
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.
(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).
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.
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.
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.
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.
[0]: https://en.wikipedia.org/wiki/List_of_legendary_creatures_by...
[1]: https://en.wikipedia.org/wiki/Bicorn_and_Chichevache