* [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) @ 2016-03-09 14:38 Lluís Vilanova 2016-03-09 15:52 ` Richard Henderson 0 siblings, 1 reply; 21+ messages in thread From: Lluís Vilanova @ 2016-03-09 14:38 UTC (permalink / raw) To: qemu-devel; +Cc: Paolo Bonzini, Richard Henderson, Peter Crosthwaite Hi, NOTE: I won't be throwing patches anytime soon, I just want to know if there's interest in this for the future. While adding events for tracing guest instructions, I've found that the per-target "gen_intermediate_code()" function is very similar but not exactly the same for each of the targets. This makes architecture-agnostic features harder to maintain across targets, specially when it comes to their relative order. So, would it be worth it if I generalized part of that code into an architecture-agnostic function that calls into target-specific hooks wherever it needs extending? There are many ways to do it that we can discuss later. Cheers, Lluis ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-09 14:38 [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) Lluís Vilanova @ 2016-03-09 15:52 ` Richard Henderson 2016-03-09 18:16 ` Lluís Vilanova 2016-03-14 12:23 ` KONRAD Frederic 0 siblings, 2 replies; 21+ messages in thread From: Richard Henderson @ 2016-03-09 15:52 UTC (permalink / raw) To: qemu-devel, Paolo Bonzini, Peter Crosthwaite On 03/09/2016 09:38 AM, Lluís Vilanova wrote: > Hi, > > NOTE: I won't be throwing patches anytime soon, I just want to know if there's > interest in this for the future. > > While adding events for tracing guest instructions, I've found that the > per-target "gen_intermediate_code()" function is very similar but not exactly > the same for each of the targets. This makes architecture-agnostic features > harder to maintain across targets, specially when it comes to their relative > order. > > So, would it be worth it if I generalized part of that code into an > architecture-agnostic function that calls into target-specific hooks wherever it > needs extending? There are many ways to do it that we can discuss later. It's worth talking about, since I do believe it would make long-term maintenance across the targets easier. These "target-specific hooks" probably ought not be "hooks" in the traditional sense of attaching them to CPUState. I'd be more comfortable with a refactoring that used include files -- maybe .h or maybe .inc.c. If we do the normal sort of hook, then we've got to either expose DisasContext in places we shouldn't, or dynamically allocate it. Neither seems particularly appealing. r~ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-09 15:52 ` Richard Henderson @ 2016-03-09 18:16 ` Lluís Vilanova 2016-03-09 18:54 ` Richard Henderson 2016-03-14 12:23 ` KONRAD Frederic 1 sibling, 1 reply; 21+ messages in thread From: Lluís Vilanova @ 2016-03-09 18:16 UTC (permalink / raw) To: Richard Henderson; +Cc: Paolo Bonzini, qemu-devel, Peter Crosthwaite Richard Henderson writes: > On 03/09/2016 09:38 AM, Lluís Vilanova wrote: >> Hi, >> >> NOTE: I won't be throwing patches anytime soon, I just want to know if there's >> interest in this for the future. >> >> While adding events for tracing guest instructions, I've found that the >> per-target "gen_intermediate_code()" function is very similar but not exactly >> the same for each of the targets. This makes architecture-agnostic features >> harder to maintain across targets, specially when it comes to their relative >> order. >> >> So, would it be worth it if I generalized part of that code into an >> architecture-agnostic function that calls into target-specific hooks wherever it >> needs extending? There are many ways to do it that we can discuss later. > It's worth talking about, since I do believe it would make long-term maintenance > across the targets easier. > These "target-specific hooks" probably ought not be "hooks" in the > traditional sense of attaching them to CPUState. I'd be more comfortable with a > refactoring that used include files -- maybe .h or maybe .inc.c. If we do the > normal sort of hook, then we've got to either expose DisasContext in places we > shouldn't, or dynamically allocate it. Neither seems particularly appealing. Great. I pondered about using QOM vs "template code", and I'm leaning towards the latter: * translate.c: struct DisasContextArch { DisasContext common; }; // implement "hooks" void gen_intermediate_code(CPUArchState *env, TranslationBlock *tb) { DisasContextArch dc; gen_intermediate_code_template(get_cpu(env), &dc.common, tb); } * translate-template.h: struct DisasContext { /* ... */ }; void gen_intermediate_code_template(CPUState *cpu, DisasContext *dc, TranslationBlock *tb) { // init dc // arch-specific init dc hook // gen_icount, etc. while (true) { // generic processing code with calls to hooks } } While initially simpler, the "template code" still feels a little dirty to me. With QOM, you could implement a DisasContextClass that provides the per-target hook pointers, which can be globally allocated once per target and pointed to by the DisasContext allocated in stack. I'm not sure about what you mean by exposing DisasContext in places it shouldn't be, though. Cheers, Lluis ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-09 18:16 ` Lluís Vilanova @ 2016-03-09 18:54 ` Richard Henderson 2016-03-09 22:29 ` Lluís Vilanova 0 siblings, 1 reply; 21+ messages in thread From: Richard Henderson @ 2016-03-09 18:54 UTC (permalink / raw) To: qemu-devel, Paolo Bonzini, Peter Crosthwaite On 03/09/2016 01:16 PM, Lluís Vilanova wrote: > Richard Henderson writes: > >> On 03/09/2016 09:38 AM, Lluís Vilanova wrote: >>> Hi, >>> >>> NOTE: I won't be throwing patches anytime soon, I just want to know if there's >>> interest in this for the future. >>> >>> While adding events for tracing guest instructions, I've found that the >>> per-target "gen_intermediate_code()" function is very similar but not exactly >>> the same for each of the targets. This makes architecture-agnostic features >>> harder to maintain across targets, specially when it comes to their relative >>> order. >>> >>> So, would it be worth it if I generalized part of that code into an >>> architecture-agnostic function that calls into target-specific hooks wherever it >>> needs extending? There are many ways to do it that we can discuss later. > >> It's worth talking about, since I do believe it would make long-term maintenance >> across the targets easier. > >> These "target-specific hooks" probably ought not be "hooks" in the >> traditional sense of attaching them to CPUState. I'd be more comfortable with a >> refactoring that used include files -- maybe .h or maybe .inc.c. If we do the >> normal sort of hook, then we've got to either expose DisasContext in places we >> shouldn't, or dynamically allocate it. Neither seems particularly appealing. > > Great. I pondered about using QOM vs "template code", and I'm leaning towards > the latter: > > * translate.c: > > struct DisasContextArch { > DisasContext common; > }; > > // implement "hooks" > > void gen_intermediate_code(CPUArchState *env, TranslationBlock *tb) > { > DisasContextArch dc; > gen_intermediate_code_template(get_cpu(env), &dc.common, tb); Pointer down into "common" here... > } > > * translate-template.h: > > struct DisasContext { /* ... */ }; > > void gen_intermediate_code_template(CPUState *cpu, DisasContext *dc, > TranslationBlock *tb) > { > // init dc > // arch-specific init dc hook > > // gen_icount, etc. > while (true) { > // generic processing code with calls to hooks ... means you have to upcast to DisasContextArch here, or in the hooks themselves. > } > } > > While initially simpler, the "template code" still feels a little dirty to > me. With QOM, you could implement a DisasContextClass that provides the > per-target hook pointers, which can be globally allocated once per target and > pointed to by the DisasContext allocated in stack. > > I'm not sure about what you mean by exposing DisasContext in places it shouldn't > be, though. You either split DisasContextArch / DisasContext in "odd" ways, and then have to cast back and forth, or you have to expose the whole of DisasContextArch. It's the latter that I considered inappropriate. Alternately... can we broach the subject of C++? Honestly, it seems we work too hard sometimes to re-implement templates and classes in C. r~ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-09 18:54 ` Richard Henderson @ 2016-03-09 22:29 ` Lluís Vilanova 2016-03-09 23:27 ` Peter Maydell 0 siblings, 1 reply; 21+ messages in thread From: Lluís Vilanova @ 2016-03-09 22:29 UTC (permalink / raw) To: Richard Henderson; +Cc: Paolo Bonzini, qemu-devel, Peter Crosthwaite Richard Henderson writes: > On 03/09/2016 01:16 PM, Lluís Vilanova wrote: >> Richard Henderson writes: >> >>> On 03/09/2016 09:38 AM, Lluís Vilanova wrote: >>>> Hi, >>>> >>>> NOTE: I won't be throwing patches anytime soon, I just want to know if there's >>>> interest in this for the future. >>>> >>>> While adding events for tracing guest instructions, I've found that the >>>> per-target "gen_intermediate_code()" function is very similar but not exactly >>>> the same for each of the targets. This makes architecture-agnostic features >>>> harder to maintain across targets, specially when it comes to their relative >>>> order. >>>> >>>> So, would it be worth it if I generalized part of that code into an >>>> architecture-agnostic function that calls into target-specific hooks wherever it >>>> needs extending? There are many ways to do it that we can discuss later. >> >>> It's worth talking about, since I do believe it would make long-term maintenance >>> across the targets easier. >> >>> These "target-specific hooks" probably ought not be "hooks" in the >>> traditional sense of attaching them to CPUState. I'd be more comfortable with a >>> refactoring that used include files -- maybe .h or maybe .inc.c. If we do the >>> normal sort of hook, then we've got to either expose DisasContext in places we >>> shouldn't, or dynamically allocate it. Neither seems particularly appealing. >> >> Great. I pondered about using QOM vs "template code", and I'm leaning towards >> the latter: >> >> * translate.c: >> >> struct DisasContextArch { >> DisasContext common; >> }; >> >> // implement "hooks" >> >> void gen_intermediate_code(CPUArchState *env, TranslationBlock *tb) >> { >> DisasContextArch dc; >> gen_intermediate_code_template(get_cpu(env), &dc.common, tb); > Pointer down into "common" here... >> } >> >> * translate-template.h: >> >> struct DisasContext { /* ... */ }; >> >> void gen_intermediate_code_template(CPUState *cpu, DisasContext *dc, >> TranslationBlock *tb) >> { >> // init dc >> // arch-specific init dc hook >> >> // gen_icount, etc. >> while (true) { >> // generic processing code with calls to hooks > ... means you have to upcast to DisasContextArch here, or in the hooks themselves. Yup, that was the intention. Hooks should then use "container_of()" to get their part. >> } >> } >> >> While initially simpler, the "template code" still feels a little dirty to >> me. With QOM, you could implement a DisasContextClass that provides the >> per-target hook pointers, which can be globally allocated once per target and >> pointed to by the DisasContext allocated in stack. >> >> I'm not sure about what you mean by exposing DisasContext in places it shouldn't >> be, though. > You either split DisasContextArch / DisasContext in "odd" ways, and then have to > cast back and forth, or you have to expose the whole of DisasContextArch. It's > the latter that I considered inappropriate. Well, moving whatever is used in the generic code into DisasContext doesn't sound too odd as a first solution. > Alternately... can we broach the subject of C++? Honestly, it seems we work too > hard sometimes to re-implement templates and classes in C. Whooo, I'd really *love* to switch to C++ just for templates and classes... But last time this was discussed, the idea wasn't met with much joy :) Cheers, Lluis ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-09 22:29 ` Lluís Vilanova @ 2016-03-09 23:27 ` Peter Maydell 2016-03-13 13:16 ` Lluís Vilanova 0 siblings, 1 reply; 21+ messages in thread From: Peter Maydell @ 2016-03-09 23:27 UTC (permalink / raw) To: Richard Henderson, QEMU Developers, Paolo Bonzini, Peter Crosthwaite On 10 March 2016 at 05:29, Lluís Vilanova <vilanova@ac.upc.edu> wrote: > Richard Henderson writes: >> Alternately... can we broach the subject of C++? Honestly, it >> seems we work too hard sometimes to re-implement templates and >> classes in C. > > Whooo, I'd really *love* to switch to C++ just for templates and > classes... But last time this was discussed, the idea wasn't met > with much joy :) I would be more interested in a proposal to move parts of QEMU to Rust, or just about anything else except C++... thanks -- PMM ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-09 23:27 ` Peter Maydell @ 2016-03-13 13:16 ` Lluís Vilanova 2016-03-13 16:25 ` Peter Maydell 0 siblings, 1 reply; 21+ messages in thread From: Lluís Vilanova @ 2016-03-13 13:16 UTC (permalink / raw) To: Peter Maydell Cc: Paolo Bonzini, Peter Crosthwaite, QEMU Developers, Richard Henderson Peter Maydell writes: > On 10 March 2016 at 05:29, Lluís Vilanova <vilanova@ac.upc.edu> wrote: >> Richard Henderson writes: >>> Alternately... can we broach the subject of C++? Honestly, it >>> seems we work too hard sometimes to re-implement templates and >>> classes in C. >> >> Whooo, I'd really *love* to switch to C++ just for templates and >> classes... But last time this was discussed, the idea wasn't met >> with much joy :) > I would be more interested in a proposal to move parts of QEMU > to Rust, or just about anything else except C++... QEMU is pretty low-level, so I'm not sure other languages will fit the bill as good, and for the parts relevant to QEMU you have just as much control of low-level details as with C (having a very close syntax also helps transition). But I'm curious, what'd be the advantage of rust? Cross-language bindings are usually expensive, and require some duplication for defining structures across them (maybe it's not the case for rust). Lluis ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-13 13:16 ` Lluís Vilanova @ 2016-03-13 16:25 ` Peter Maydell 2016-03-14 7:06 ` Markus Armbruster 0 siblings, 1 reply; 21+ messages in thread From: Peter Maydell @ 2016-03-13 16:25 UTC (permalink / raw) To: Peter Maydell, Richard Henderson, QEMU Developers, Paolo Bonzini, Peter Crosthwaite On 13 March 2016 at 13:16, Lluís Vilanova <vilanova@ac.upc.edu> wrote: > Peter Maydell writes: >> I would be more interested in a proposal to move parts of QEMU >> to Rust, or just about anything else except C++... > > QEMU is pretty low-level, so I'm not sure other languages will fit the bill as > good, and for the parts relevant to QEMU you have just as much control of > low-level details as with C (having a very close syntax also helps > transition). > > But I'm curious, what'd be the advantage of rust? Cross-language > bindings are usually expensive, and require some duplication for > defining structures across them (maybe it's not the case for rust). It's a systems programming language that's not insanely huge and designed by continuous accretion of features, that's all. (More positively, it has the usual nice features of newer languages such as not letting you write code that's exploitable by a malicious guest via buffer overflows.) But I'm not so much trying to advocate for Rust (which I have not investigated at all) as expressing an opinion that 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. thanks -- PMM ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-13 16:25 ` Peter Maydell @ 2016-03-14 7:06 ` Markus Armbruster 2016-03-14 11:13 ` Lluís Vilanova 2016-04-03 13:05 ` Lluís Vilanova 0 siblings, 2 replies; 21+ messages in thread From: Markus Armbruster @ 2016-03-14 7:06 UTC (permalink / raw) To: Peter Maydell Cc: Paolo Bonzini, Peter Crosthwaite, QEMU Developers, Richard Henderson Peter Maydell <peter.maydell@linaro.org> writes: [...] > 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. Seconded strongly. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-14 7:06 ` Markus Armbruster @ 2016-03-14 11:13 ` Lluís Vilanova 2016-04-03 13:05 ` Lluís Vilanova 1 sibling, 0 replies; 21+ messages in thread From: Lluís Vilanova @ 2016-03-14 11:13 UTC (permalink / raw) To: Markus Armbruster Cc: Peter Maydell, Richard Henderson, Peter Crosthwaite, QEMU Developers, Paolo Bonzini Markus Armbruster writes: > Peter Maydell <peter.maydell@linaro.org> writes: > [...] >> 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. > Seconded strongly. I don't feel like that about C++, but then I maybe had a different experience with it (specially with the latest standard additions). Cheers, Lluis ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-14 7:06 ` Markus Armbruster 2016-03-14 11:13 ` Lluís Vilanova @ 2016-04-03 13:05 ` Lluís Vilanova 2016-04-07 14:27 ` Markus Armbruster 2016-04-07 14:49 ` Peter Maydell 1 sibling, 2 replies; 21+ messages in thread From: Lluís Vilanova @ 2016-04-03 13:05 UTC (permalink / raw) To: Markus Armbruster Cc: Peter Maydell, Richard Henderson, Peter Crosthwaite, QEMU Developers, Paolo Bonzini Markus Armbruster writes: > Peter Maydell <peter.maydell@linaro.org> writes: > [...] >> 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. > Seconded strongly. Just curious. Do we agree though that moving selected pieces like the code templates with macros to C++ templated functions, or QOM to C++ classes would be an improvement over the current C code without any dramatic changes in the codebase? (I don't think more than that is needed) Cheers, Lluis ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-04-03 13:05 ` Lluís Vilanova @ 2016-04-07 14:27 ` Markus Armbruster 2016-04-07 14:49 ` Peter Maydell 1 sibling, 0 replies; 21+ messages in thread From: Markus Armbruster @ 2016-04-07 14:27 UTC (permalink / raw) To: Peter Maydell Cc: Paolo Bonzini, Richard Henderson, QEMU Developers, Peter Crosthwaite Lluís Vilanova <vilanova@ac.upc.edu> writes: > Markus Armbruster writes: > >> Peter Maydell <peter.maydell@linaro.org> writes: >> [...] >>> 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. > >> Seconded strongly. > > Just curious. Do we agree though that moving selected pieces like the code > templates with macros to C++ templated functions, or QOM to C++ classes would be > an improvement over the current C code without any dramatic changes in the > codebase? (I don't think more than that is needed) I don't think we do. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-04-03 13:05 ` Lluís Vilanova 2016-04-07 14:27 ` Markus Armbruster @ 2016-04-07 14:49 ` Peter Maydell 2016-04-07 15:01 ` Paolo Bonzini 1 sibling, 1 reply; 21+ messages in thread From: Peter Maydell @ 2016-04-07 14:49 UTC (permalink / raw) To: Markus Armbruster, Peter Maydell, Paolo Bonzini, Peter Crosthwaite, QEMU Developers, Richard Henderson On 3 April 2016 at 14:05, Lluís Vilanova <vilanova@ac.upc.edu> wrote: > QOM to C++ classes I suspect if you looked at this you'd find that the QOM semantics for various things don't map onto C++ (ie that we have more runtime flexibility than C++ does). This is just vaguely remembered from discussions back when we first added QOM though, I have no specific detail and might have misremembered. thanks -- PMM ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-04-07 14:49 ` Peter Maydell @ 2016-04-07 15:01 ` Paolo Bonzini 2016-04-08 13:15 ` Markus Armbruster 0 siblings, 1 reply; 21+ messages in thread From: Paolo Bonzini @ 2016-04-07 15:01 UTC (permalink / raw) To: Peter Maydell, Markus Armbruster, Peter Crosthwaite, QEMU Developers, Richard Henderson On 07/04/2016 16:49, Peter Maydell wrote: > > QOM to C++ classes > I suspect if you looked at this you'd find that the QOM semantics > for various things don't map onto C++ (ie that we have more runtime > flexibility than C++ does). True, but you don't have to use it. :) If your code is static, one could imagine bindings to C++ that eliminate some of the boilerplate. Don't look at me, though. 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 cleanups that Markus started and I want to conclude very early in 2.7). Paolo > This is just vaguely remembered from > discussions back when we first added QOM though, I have no specific > detail and might have misremembered. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-04-07 15:01 ` Paolo Bonzini @ 2016-04-08 13:15 ` Markus Armbruster 2016-04-08 14:14 ` Paolo Bonzini 0 siblings, 1 reply; 21+ messages in thread From: Markus Armbruster @ 2016-04-08 13:15 UTC (permalink / raw) To: Paolo Bonzini Cc: Peter Maydell, Peter Crosthwaite, QEMU Developers, Richard Henderson Paolo Bonzini <pbonzini@redhat.com> writes: > On 07/04/2016 16:49, Peter Maydell wrote: >> > QOM to C++ classes >> I suspect if you looked at this you'd find that the QOM semantics >> for various things don't map onto C++ (ie that we have more runtime >> flexibility than C++ does). > > True, but you don't have to use it. :) If your code is static, one > could imagine bindings to C++ that eliminate some of the boilerplate. > Don't look at me, though. > > 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." 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. We're bad enough at getting everybody write half-decent C, and making the problem harder is unlikely to help. > 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? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-04-08 13:15 ` Markus Armbruster @ 2016-04-08 14:14 ` Paolo Bonzini 2016-04-11 5:50 ` Claudio Fontana 0 siblings, 1 reply; 21+ messages in thread From: Paolo Bonzini @ 2016-04-08 14:14 UTC (permalink / raw) To: Markus Armbruster Cc: Peter Maydell, Peter Crosthwaite, QEMU Developers, Richard Henderson 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 base. > 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 screen. 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. Paolo ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-04-08 14:14 ` Paolo Bonzini @ 2016-04-11 5:50 ` Claudio Fontana 2016-04-11 13:11 ` Lluís Vilanova 0 siblings, 1 reply; 21+ messages in thread From: Claudio Fontana @ 2016-04-11 5:50 UTC (permalink / raw) To: Paolo Bonzini, Markus Armbruster Cc: Peter Maydell, Richard Henderson, QEMU Developers, Peter Crosthwaite 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 > base. 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? Thank you, Claudio > >> 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 > screen. > > 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. > > Paolo > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-04-11 5:50 ` Claudio Fontana @ 2016-04-11 13:11 ` Lluís Vilanova 0 siblings, 0 replies; 21+ messages in thread From: Lluís Vilanova @ 2016-04-11 13:11 UTC (permalink / raw) To: Claudio Fontana Cc: Paolo Bonzini, Markus Armbruster, Peter Maydell, Peter Crosthwaite, QEMU Developers, Richard Henderson Claudio Fontana writes: > 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 >> base. > 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? For templates, binary size and startup time should be exactly the same (plus whatever fixed costs C++ might have, if any at all). Compilation times really depend on the complexity of the templates, but I think that a straight conversion should not noticeably increase compilation times; the use of templates that QEMU would have is pretty straightforward (not any complex interrelation between different templated classes with their own templated methods), and we'd be replacing the preprocessing of a file multiple times (e.g., include softmmu_template.h 8 times) for templated functions in the implementation file (no need to see templates on the headers). In the case of objects, binary/memory size should be marginally lower with C++ (in some cases, the C++ compiler can elide the "parent_class" pointer that QEMU adds on every object class). On startup time, I'm not aware of any costs added by C++ objects, but I might be wrong (aren't vtable pointers prepared at compilation time?). As for compilation time, I really don't know what important effects classes can have. Cheers, Lluis ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-09 15:52 ` Richard Henderson 2016-03-09 18:16 ` Lluís Vilanova @ 2016-03-14 12:23 ` KONRAD Frederic 2016-03-14 14:14 ` Paolo Bonzini 2016-03-14 14:26 ` Lluís Vilanova 1 sibling, 2 replies; 21+ messages in thread From: KONRAD Frederic @ 2016-03-14 12:23 UTC (permalink / raw) To: Richard Henderson, qemu-devel; +Cc: Paolo Bonzini, Peter Crosthwaite Hi, Le 09/03/2016 16:52, Richard Henderson a écrit : > On 03/09/2016 09:38 AM, Lluís Vilanova wrote: >> Hi, >> >> NOTE: I won't be throwing patches anytime soon, I just want to know >> if there's >> interest in this for the future. >> >> While adding events for tracing guest instructions, I've found that the >> per-target "gen_intermediate_code()" function is very similar but not >> exactly >> the same for each of the targets. This makes architecture-agnostic >> features >> harder to maintain across targets, specially when it comes to their >> relative >> order. >> >> So, would it be worth it if I generalized part of that code into an >> architecture-agnostic function that calls into target-specific hooks >> wherever it >> needs extending? There are many ways to do it that we can discuss later. > > It's worth talking about, since I do believe it would make long-term > maintenance across the targets easier. > > These "target-specific hooks" probably ought not be "hooks" in the > traditional sense of attaching them to CPUState. I'd be more > comfortable with a refactoring that used include files -- maybe .h or > maybe .inc.c. If we do the normal sort of hook, then we've got to > either expose DisasContext in places we shouldn't, or dynamically > allocate it. Neither seems particularly appealing. > > > r~ > On the other side I think attaching them to CPUState would make heterogenous system emulation easier? Fred ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-14 12:23 ` KONRAD Frederic @ 2016-03-14 14:14 ` Paolo Bonzini 2016-03-14 14:26 ` Lluís Vilanova 1 sibling, 0 replies; 21+ messages in thread From: Paolo Bonzini @ 2016-03-14 14:14 UTC (permalink / raw) To: KONRAD Frederic, Richard Henderson, qemu-devel; +Cc: Peter Crosthwaite On 14/03/2016 13:23, KONRAD Frederic wrote: >> These "target-specific hooks" probably ought not be "hooks" in the >> traditional sense of attaching them to CPUState. I'd be more >> comfortable with a refactoring that used include files -- maybe .h or >> maybe .inc.c. If we do the normal sort of hook, then we've got to >> either expose DisasContext in places we shouldn't, or dynamically >> allocate it. Neither seems particularly appealing. > > On the other side I think attaching them to CPUState would make > heterogenous system emulation easier? It depends on whether they're going to be called from generic code. As long as they are only called from other CPU-specific bits, adding them to CPUState isn't necessary. Paolo ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) 2016-03-14 12:23 ` KONRAD Frederic 2016-03-14 14:14 ` Paolo Bonzini @ 2016-03-14 14:26 ` Lluís Vilanova 1 sibling, 0 replies; 21+ messages in thread From: Lluís Vilanova @ 2016-03-14 14:26 UTC (permalink / raw) To: KONRAD Frederic Cc: Paolo Bonzini, Peter Crosthwaite, qemu-devel, Richard Henderson KONRAD Frederic writes: > Hi, > Le 09/03/2016 16:52, Richard Henderson a écrit : >> On 03/09/2016 09:38 AM, Lluís Vilanova wrote: >>> Hi, >>> >>> NOTE: I won't be throwing patches anytime soon, I just want to know if >>> there's >>> interest in this for the future. >>> >>> While adding events for tracing guest instructions, I've found that the >>> per-target "gen_intermediate_code()" function is very similar but not exactly >>> the same for each of the targets. This makes architecture-agnostic features >>> harder to maintain across targets, specially when it comes to their relative >>> order. >>> >>> So, would it be worth it if I generalized part of that code into an >>> architecture-agnostic function that calls into target-specific hooks wherever >>> it >>> needs extending? There are many ways to do it that we can discuss later. >> >> It's worth talking about, since I do believe it would make long-term >> maintenance across the targets easier. >> >> These "target-specific hooks" probably ought not be "hooks" in the >> traditional sense of attaching them to CPUState. I'd be more comfortable with >> a refactoring that used include files -- maybe .h or maybe .inc.c. If we do >> the normal sort of hook, then we've got to either expose DisasContext in >> places we shouldn't, or dynamically allocate it. Neither seems particularly >> appealing. >> >> >> r~ >> > On the other side I think attaching them to CPUState would make heterogenous > system emulation easier? Yes, that's something to take into account too. But for this I think that "gen_intermediate_code()" would suffice. Still, abstracting it into the level of KVM vs. TCG would be even more interesting, since we could switch between backends, or even have different CPUs using different backends (e.g., trace a TCG vCPU while another runs at full speed using KVM). For example, there could be a virtual "exec()" method, although reality is not that straightforward since each KVM vCPU runs on a different thread, while in TCG this is not necessarily so (even with MTTCG). Cheers, Lluis ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2016-04-11 13:11 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-03-09 14:38 [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) Lluís Vilanova 2016-03-09 15:52 ` Richard Henderson 2016-03-09 18:16 ` Lluís Vilanova 2016-03-09 18:54 ` Richard Henderson 2016-03-09 22:29 ` Lluís Vilanova 2016-03-09 23:27 ` Peter Maydell 2016-03-13 13:16 ` Lluís Vilanova 2016-03-13 16:25 ` Peter Maydell 2016-03-14 7:06 ` Markus Armbruster 2016-03-14 11:13 ` Lluís Vilanova 2016-04-03 13:05 ` Lluís Vilanova 2016-04-07 14:27 ` Markus Armbruster 2016-04-07 14:49 ` Peter Maydell 2016-04-07 15:01 ` Paolo Bonzini 2016-04-08 13:15 ` Markus Armbruster 2016-04-08 14:14 ` Paolo Bonzini 2016-04-11 5:50 ` Claudio Fontana 2016-04-11 13:11 ` Lluís Vilanova 2016-03-14 12:23 ` KONRAD Frederic 2016-03-14 14:14 ` Paolo Bonzini 2016-03-14 14:26 ` Lluís Vilanova
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.