On Tue, Feb 1, 2011 at 13:45, Peter Maydell wrote:
> On 1 February 2011 18:16, Mike Frysinger wrote:
>> On Tue, Feb 1, 2011 at 12:30, Peter Maydell wrote:
>>> That's OK too, that would fall into my category (3).
>>
>> so the TB invalidation checking can be taken care of implicitly if i
>> handled t
On Tue, Feb 1, 2011 at 05:31, Peter Maydell wrote:
> So for instance here:
>
> +static void gen_hwloop_check(DisasContext *dc)
> +{
> + bool loop1, loop0;
> + int endl;
> +
> + loop1 = (dc->pc == dc->env->lbreg[1]);
> + loop0 = (dc->pc == dc->env->lbreg[0]);
>
> I suspect that this chec
On 1 February 2011 17:20, Mike Frysinger wrote:
> On Tue, Feb 1, 2011 at 05:31, Peter Maydell wrote:
>> I suspect that this check of pc against the lbreg[]
>> values should be being done in the generated code,
>> not at translate time.
> the way i'm doing it atm i believe is safe. if a lbreg cha
On 1 February 2011 18:16, Mike Frysinger wrote:
> On Tue, Feb 1, 2011 at 12:30, Peter Maydell wrote:
>> That's OK too, that would fall into my category (3).
>
> so the TB invalidation checking can be taken care of implicitly if i
> handled things in cpu_get_tb_cpu_state() ? that would be nice.
I
On Tue, Feb 1, 2011 at 12:30, Peter Maydell wrote:
> On 1 February 2011 17:20, Mike Frysinger wrote:
>> On Tue, Feb 1, 2011 at 05:31, Peter Maydell wrote:
>>> I suspect that this check of pc against the lbreg[]
>>> values should be being done in the generated code,
>>> not at translate time.
>>
>>
On 1 February 2011 11:46, Alexander Graf wrote:
> Ouch. Yes. General rule: never access env from translate.c :).
With the arm target I was tempted to restructure translate.c so
that we copied the handful of "safe" bits of env that we used
into the disas context struct right at the start, and the
On 01.02.2011, at 11:31, Peter Maydell wrote:
> On 1 February 2011 09:38, Alexander Graf wrote:
>> On 01.02.2011, at 05:19, Mike Frysinger wrote:
>>> On Mon, Jan 31, 2011 at 09:00, Edgar E. Iglesias wrote:
* cpu_get_tb_cpu_state() doesn't define any tb flags?
>>>
>>> no idea what this func
On 1 February 2011 09:38, Alexander Graf wrote:
> On 01.02.2011, at 05:19, Mike Frysinger wrote:
>> On Mon, Jan 31, 2011 at 09:00, Edgar E. Iglesias wrote:
>>> * cpu_get_tb_cpu_state() doesn't define any tb flags?
>>
>> no idea what this func is supposed to do
>
> Qemu uses the tb flags as identif
On 01.02.2011, at 05:19, Mike Frysinger wrote:
> On Mon, Jan 31, 2011 at 09:00, Edgar E. Iglesias wrote:
>> * Some operations seem to translate to large amounts of tcg code,
>> maybe you should consider using helpers for those. An example
>> is gen_rot_tl.
>
> seems like generated native code
On Mon, Jan 31, 2011 at 09:00, Edgar E. Iglesias wrote:
> * Some operations seem to translate to large amounts of tcg code,
> maybe you should consider using helpers for those. An example
> is gen_rot_tl.
seems like generated native code is better even if it is larger
> * Maybe you should renam
On Mon, Jan 24, 2011 at 05:23:01AM -0500, Mike Frysinger wrote:
> I finally got around to getting this port past the "only crashes" phase.
> Using the GNU sim Blackfin port as a nice working standard, it was just
> a matter of replacing the sim bits with TCG ops. Now we have a linux-user
> port fo
I finally got around to getting this port past the "only crashes" phase.
Using the GNU sim Blackfin port as a nice working standard, it was just
a matter of replacing the sim bits with TCG ops. Now we have a linux-user
port for people to play with. No immediate plans to move on to the system
step
12 matches
Mail list logo
