[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation
Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code)
Mon, 11 Apr 2016 13:50:51 +0800
Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
Clearly late to the party,
On 08.04.2016 22:14, Paolo Bonzini wrote:
> On 08/04/2016 15:15, Markus Armbruster wrote:
>>> On the other hand, minimal usage of templates instead of some of the
>>> preprocessor gunk we have would be a very good thing IMNSHO. I am
>>> referring to the multiply included header files and to the macros with
>>> type arguments (mostly QOM casts).
>>> I don't think we need more C++ than that, but using templates as
>>> basically a type-safe preprocessor would improve QEMU a little bit.
>>> More rarely, lambdas could replace some preprocessor magic too, but
>>> that's C11 and not many compilers support them.
>>> But I won't weep if people say no because we have a lot other
>>> low-hanging fruit to make QEMU better (especially the header file
>> "No!" (Hey, you asked for it)
>> Back to serious. As Peter Maydell said, "if we move away from C I'd
>> rather it to be a language that's nicer than C rather than one that's
>> uglier and larger and still retains all of C's flaws."
> Sure, except that one plan is feasible now and can be done in small
> steps; the other is not feasible now (for example Rust is not even
> packaged in Fedora) and entails pretty much a rewrite of the whole code
I skip my personal take on these specific issue, but one very practical concern
I have with a potential move to C++,
if I understand these proposals correctly, is with the speed of compilation and
the binary size, and also QEMU startup time.
I noticed while developing for OSv that compilation with C++ and templates was
very slow compared with C, so certain scripts around git I am using to build
and check code from scratch after each patch took a long time to complete.
Do you know what these refactoring proposals' impact on compilation speed,
binary size and startup time would be?
>> People sometimes propose to defang C++ by subsetting and/or coding
>> conventions. I'll take that seriously when I see the tool that
>> rigorously checks adherence to subset / convention.
> The problem with subsetting and conventions is that they always come
> with exceptions, besides the fact that no one writes the tool.
> So I prefer common sense :) and common sense says that a million-line
> codebase that mixes procedural, home-grown OO and language OO is going
> to stink from ten miles. And maintainers sit at most two feet from the
> Really even just -Wc++-compat would be a nice improvement so we enjoy a
> little more type safety. IMHO, C++'s biggest tax is that Coccinelle
> does not like it.
>>> cleanups that Markus started and I want to conclude very early in 2.7).
>> Speaking of which: the plan was you post yours for 2.7, and then I can
>> build on top (assuming there's useful work left), right?
> I have rebased my stuff already, but I'm going to disappear in about a
> week and for the first week or two after the 2.6 release (depending on
> whether it slips or not). Also, I will travel most of next week. So I
> either I'll post it soonish or it will have to wait a little.
> Anyhow, there's definitely useful work left from your last two patches,
> even more so after Veronia Bahaa cleaned up qemu-common.h substantially
> so there may be more pointless inclusions of it and fewer headers that
> really need it.