Live data from Hacker News

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

unicorn-engine.org

31–40 of 42 posts

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

#31
post #7

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?

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

#32
post #8

Earlier quoted context omitted.

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

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 in…

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

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

#33
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.

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

#35
post #9

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…

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.

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

#36
post #11
post #9

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…

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.

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

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

#37
post #7

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?

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

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

#38
post #19
post #10

Earlier quoted context omitted.

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

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

#39
post #11
post #9

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…

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.

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.
Post reply on HN