21–30 of 42 posts
QEMU supports PowerPC, but this appears not to.
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.
So, PPC support was one one of first considerations looking at Unicorn. Thanks for posting that it's partly there.
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…
Why didn't they name it Multicorn?
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.
> 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.
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…
Why didn't they name it Multicorn?
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…
Why didn't they name it Multicorn?
There's precdent for "Omnicorn" [1]-- after all, "On its head is every manner of horn".
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 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.
Edit: Looks like they are based on QEMU.