On Tue, 29 Nov 2016 17:26:59 +0100 Paolo Bonzini <pbonz...@redhat.com> wrote:
> It's pretty clean! I would rather avoid the duplicate enums, possibly > by automatically generating large parts of ptc.h, but that's pretty > much it. I see that you check that the constants match (that cpp > stuff is disgusting :)), and that is already a good thing. Does QEMU already have some mechanism to generate code? Otherwise I can try to factor out the enum in a file that can be included in multiple places. > As to dumping the assembly code, I think that's beyond the scope of > QEMU---rather, if there is an existing library to do so, QEMU would > like to use it because currently we're stuck with an old > GPLv2-compatible version of GNU binutils. For everything else it > makes sense to use a "librarified" QEMU frontend and even backend. My idea was to offer it externally, if available, more for debugging purposes than for actual usage, in a "best-effort" way, let's say. Isolating the backend too makes sense, but I'm not sure how much interest there is on this, I'll first focus on exposing the frontends, which is the killer feature for many of us. > It would even be better, I think, to make linux-user a client of the > library itself, because this will prevent bitrot. This is something I didn't think about, it might be interesting indeed. But why only linux-user and not full system emulation too? > As to the helpers, QEMU has annotations of helpers that read globals, > write globals or have side effects. However, they are pretty new so > they aren't used too much. In general we prefer new helpers to be > pure, but this is not true of much legacy code that dates back to > even before TCG (i.e. ~2008). If most how the new helpers will be pure it might make sense to make a one-time effort to annotate existing helpers with the list of parts of the CPU they might access. I currently have an LLVM pass which analyzes the helpers and collect programmatically this information. This might be used for an initial collection of such information, or maybe even run periodically (before each release?). However, I'd leave discussion for this things for later. In the coming weeks I'll try to come up with some self-contained patches for review. On Tue, 29 Nov 2016 18:55:24 +0200 Liviu Ionescu <i...@livius.net> wrote: > if you manage to make the TCG frontend as a library, it would be > great to check that it can also be used from C++. > > the current QEMU headers prevent this, by using C++ reserved words > (like `class`), which is a real pity. I'm already using it from C++ (see rev.ng)! Users only need to include ptc.h, nothing else. Thanks for your responses, expect patches. -- Alessandro Di Federico PhD student at Politecnico di Milano
