On 01.03.2012 11:51, 陳韋任 wrote:
If you're serious about multithreading TCG then I think the first
steps are:
* fix existing race conditions
* think very hard
* come up with an overall design for what you're proposing
As COREMU [1] point out, current QEMU atomic instruction emulation ap
On 01.03.2012 12:27, Peter Maydell wrote:
On 1 March 2012 08:22, Andreas Färber wrote:
Am 28.02.2012 04:13, schrieb Evgeny Voevodin:
On 27.02.2012 16:35, Peter Maydell wrote:
A true multithreaded TCG is a large project, and unless we're
going to commit to doing that I don't see much value in
> If you're serious about multithreading TCG then I think the first
> steps are:
> * fix existing race conditions
> * think very hard
> * come up with an overall design for what you're proposing
As COREMU [1] point out, current QEMU atomic instruction emulation approach is
problematic. For ex
On 1 March 2012 08:22, Andreas Färber wrote:
> Am 28.02.2012 04:13, schrieb Evgeny Voevodin:
>> On 27.02.2012 16:35, Peter Maydell wrote:
>>> A true multithreaded TCG is a large project, and unless we're
>>> going to commit to doing that I don't see much value in making
>>> some variables per-thre
Am 28.02.2012 04:13, schrieb Evgeny Voevodin:
> On 27.02.2012 16:35, Peter Maydell wrote:
>> A true multithreaded TCG is a large project, and unless we're
>> going to commit to doing that I don't see much value in making
>> some variables per-thread when we might instead need to do
>> larger refact
> Certainly would :) Also I've studied COREMU:
> http://ppi.fudan.edu.cn/_media/publications%3Bcoremu-ppopp11.pdf
> But they are based on v0.14 as I can remember and seems that this
> project is not going to come upstream.
> Anyway, thee are a lot of useful approaches they done while facing
> di
On Tue, Feb 28, 2012 at 08:10:58AM +, Peter Maydell wrote:
> On 28 February 2012 03:13, Evgeny Voevodin wrote:
> > I wanted to get some feedback and points to show up a direction to move in
> > this field.
> > And qomification of translation caches is an interesting suggestion I think.
>
> If
On 29.02.2012 07:46, 陳韋任 wrote:
Certainly would :) Also I've studied COREMU:
http://ppi.fudan.edu.cn/_media/publications%3Bcoremu-ppopp11.pdf
But they are based on v0.14 as I can remember and seems that this
project is not going to come upstream.
Anyway, thee are a lot of useful approaches they d
On 29.02.2012 07:26, 陳韋任 wrote:
On Tue, Feb 28, 2012 at 08:10:58AM +, Peter Maydell wrote:
On 28 February 2012 03:13, Evgeny Voevodin wrote:
I wanted to get some feedback and points to show up a direction to move in
this field.
And qomification of translation caches is an interesting sugge
On 28 February 2012 03:13, Evgeny Voevodin wrote:
> I wanted to get some feedback and points to show up a direction to move in
> this field.
> And qomification of translation caches is an interesting suggestion I think.
If you're serious about multithreading TCG then I think the first
steps are:
On 27.02.2012 16:35, Peter Maydell wrote:
On 27 February 2012 12:13, Evgeny Voevodin wrote:
This commit converts code_gen_buffer, code_gen_ptr, tbs, nb_tbs to
TLS. We need this if we want TCG to become multithreaded.
I'm sceptical about doing this kind of thing as a change on its
own. A true m
On 27 February 2012 12:13, Evgeny Voevodin wrote:
> This commit converts code_gen_buffer, code_gen_ptr, tbs, nb_tbs to
> TLS. We need this if we want TCG to become multithreaded.
I'm sceptical about doing this kind of thing as a change on its
own. A true multithreaded TCG is a large project, and
This commit converts code_gen_buffer, code_gen_ptr, tbs, nb_tbs to
TLS. We need this if we want TCG to become multithreaded.
Initialization of code_gen_buffer and code_gen_ptr is moved to new
tcg_gen_buffer_init() function. This is done because we do not need
to allocate and initialize TCG buffers
13 matches
Mail list logo
