Hello all, I have a question about icount and tb chaining that I hope
somebody can clear up. In cpu-exec.c, when the icount_decr.u16.low
counter expires, it passes back the current tb as the next_tb and add
a jump with the least significant bits = 2. This falls through to tb
add jump, which then u
Hello all, I have a question about icount and tb chaining that I hope
somebody can clear up. In cpu-exec.c, when the icount_decr.u16.low
counter expires, it passes back the current tb as the next_tb and add
a jump with the least significant bits = 2. This falls through to tb
add jump, which then u
On Thu, Jan 12, 2012 at 11:00:43AM -0800, James Greensky wrote:
> Hello all, I have a question about icount and tb chaining that I hope
> somebody can clear up. In cpu-exec.c, when the icount_decr.u16.low
> counter expires, it passes back the current tb as the next_tb and add
> a jump with the lea
Sure, usually a tb chain is setup after a subsequent tb is
found/constructed in the loop in cpu_exec when a tb returns.
Taken/non-taken branch chaining is implemented by indicating the
branch direction by the two least significant digits of the the
previously returned tb. This is usually 0/1. When
> a jump with the least significant bits = 2. This falls through to tb
> add jump, which then updates the jmp_first field of the current tb.
I don't know if tb_add_jump's second parameter will be two or not, but
look at TranslationBlock (exec-all.h),
struct TranslationBlock {
struct Translat
2012/1/13 James Greensky :
> Sure, usually a tb chain is setup after a subsequent tb is
> found/constructed in the loop in cpu_exec when a tb returns.
> Taken/non-taken branch chaining is implemented by indicating the
> branch direction by the two least significant digits of the the
> previously re
On Tue, Jan 17, 2012 at 7:06 AM, 陳韋任 wrote:
>> a jump with the least significant bits = 2. This falls through to tb
>> add jump, which then updates the jmp_first field of the current tb.
>
> I don't know if tb_add_jump's second parameter will be two or not, but
> look at TranslationBlock (exec-al
On Tue, Jan 17, 2012 at 10:50 AM, Peter Maydell
wrote:
> 2012/1/13 James Greensky :
>> Sure, usually a tb chain is setup after a subsequent tb is
>> found/constructed in the loop in cpu_exec when a tb returns.
>> Taken/non-taken branch chaining is implemented by indicating the
>> branch direction
On Tue, Jan 17, 2012 at 7:50 PM, Peter Maydell wrote:
> 2012/1/13 James Greensky :
>> Sure, usually a tb chain is setup after a subsequent tb is
>> found/constructed in the loop in cpu_exec when a tb returns.
>> Taken/non-taken branch chaining is implemented by indicating the
>> branch direction b
On Tue, Jan 17, 2012 at 8:06 PM, Laurent Desnogues
wrote:
> On Tue, Jan 17, 2012 at 7:50 PM, Peter Maydell
> wrote:
>> 2012/1/13 James Greensky :
>>> Sure, usually a tb chain is setup after a subsequent tb is
>>> found/constructed in the loop in cpu_exec when a tb returns.
>>> Taken/non-taken br
> if (!tb->jmp_next[n]) { <--- what if n is 2?
>
> This is my question, if n is two, it would actually be checking the
> jmp_first field immediatedly following the jmp_next array in the tb
> structure. This function only updates the jmp_first field and doesn't
> touch jmp_next when n is 2. Does a
> previously returned tb. This is usually 0/1. When running icount, you
> can also get a 2 value in these least significant digits, indicating
> that the translation block was restarted due to the
> icount_decr.u16.low field being exhausted but having instructions left
> to execute in icount_extra.
On Tue, Jan 17, 2012 at 7:03 PM, 陳韋任 wrote:
>> if (!tb->jmp_next[n]) { <--- what if n is 2?
>>
>> This is my question, if n is two, it would actually be checking the
>> jmp_first field immediatedly following the jmp_next array in the tb
>> structure. This function only updates the jmp_first field
On Tue, Jan 17, 2012 at 7:22 PM, 陳韋任 wrote:
>> previously returned tb. This is usually 0/1. When running icount, you
>> can also get a 2 value in these least significant digits, indicating
>> that the translation block was restarted due to the
>> icount_decr.u16.low field being exhausted but havin
On 18 January 2012 19:43, James Greensky wrote:
> On Tue, Jan 17, 2012 at 7:03 PM, 陳韋任 wrote:
>> I think those numbers (0, 1, and 2) means tb_add_jump 2nd parameter here, so
>> it's intentionally to check jmp_first when n is 2. Since tb->jmp_first is
>> never
>> to be zero, then condition is alw
> What i mean here is that in gen-icount.h, the icount_decr.u32 field is
> exhausted and jumps out to the cpu-exec loop. This is where you would
> fall into tb_add_jump with the second argument being 2, and only if
> icount_extra was greater than zero. This is what I meant, and
> previously you sho
On Wed, Jan 18, 2012 at 07:50:19PM +, Peter Maydell wrote:
> On 18 January 2012 19:43, James Greensky wrote:
> > On Tue, Jan 17, 2012 at 7:03 PM, 陳韋任 wrote:
> >> I think those numbers (0, 1, and 2) means tb_add_jump 2nd parameter here,
> >> so
> >> it's intentionally to check jmp_first when
On Thu, Jan 19, 2012 at 2:32 AM, 陳韋任 wrote:
>> What i mean here is that in gen-icount.h, the icount_decr.u32 field is
>> exhausted and jumps out to the cpu-exec loop. This is where you would
>> fall into tb_add_jump with the second argument being 2, and only if
>> icount_extra was greater than zer
18 matches
Mail list logo
