qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Blue Swirl <blauwirbel@gmail.com>
To: Artyom Tarasenko <atar4qemu@googlemail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: target-sparc/TODO
Date: Wed, 19 Aug 2009 19:43:21 +0300	[thread overview]
Message-ID: <f43fc5580908190943y733cb56dvf35af9c9a325235a@mail.gmail.com> (raw)
In-Reply-To: <fb8d4f70908190317qe2f1df8rd2cb02504d1406e8@mail.gmail.com>

On Wed, Aug 19, 2009 at 1:17 PM, Artyom
Tarasenko<atar4qemu@googlemail.com> wrote:
> 2009/8/17 Blue Swirl <blauwirbel@gmail.com>:
>> On Mon, Aug 17, 2009 at 1:52 PM, Artyom
>> Tarasenko<atar4qemu@googlemail.com> wrote:
>>>> - Global register for regwptr, so that windowed registers can be
>>>> accessed directly
>>>
>>> looks like it's already implemented?
>>
>> No, this means that a global register (TCG_AREG1) would be designated
>> as regwptr, so that the window registers (%o, %l, %i) would be defined
>> with:
>>
>> cpu_wregs[i] = tcg_global_mem_new(TCG_AREG1, offsetof(...), name).
>>
>> This would need some changes to cwp handling to support TCG_AREG1,
>> maybe also to TCG prologue.
>>
>> Before TCG, this was difficult because the registers were taken by
>> cpu_T0, cpu_T1 and cpu_T2.
>>
>> But it's not clear if this gives any performance gain, because
>> although window registers accesses may get faster (this is also not
>> certain because CPUstate should reside in cache), there is one host
>> register less available and that may mean more host memory accesses.
>
> So, it's only about performance, otherwise the current implementation
> is complete?

Yes. Sparc64/V9 side is less complete.

>>>> - Synthetic instructions
>>> Is it still open?
>>
>> We already handle 'clr' and 'mov'. Code generation is not optimal, for
>> example arithmetic ops with constants/%g0 or things like wrpsr which
>> always does a XOR of the parameters even if they are constants or %g0.
>
> Would the synthetic ops with %g0 produce wrong results?
> Particularly I'm interested if
>
> jmp     %l1, %g4, %g0
>
> may behave other than on a real hw.

No, if rd is %g0, the current PC will not be written anywhere (not by
real HW either). This is handled by translate.c:4041 call to
gen_movl_TN_reg(), which suppresses the move if rd is zero. Likewise
for other rd writeback.

This class of instructions ("op %x, %y, %g0") should be close to
optimal except for degenerate cases like "and %g1, 1, %g0" which
should not generate any code at all. "andcc %g1, 1, %g0" should and it
does.

I meant that "wrpsr %g1, 0" (or %g0) should suppress the useless XOR
of %g1 and 0.

>>>> - Hardware breakpoint/watchpoint support
>>> Is it still open?
>>
>> I think support for these was only found in a few CPU models, so they
>> are not used much. Nobody has also shown any interest or provided a
>> test case.
>
>
> On OBP start-up I see some "write breakpoint reg" messages in the
> debug log. Do they have to do with hardware breakpoint support?
>

Yes, or they could also be MMU breakpoint registers.

  reply	other threads:[~2009-08-19 16:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-17 10:52 [Qemu-devel] target-sparc/TODO Artyom Tarasenko
2009-08-17 17:35 ` [Qemu-devel] target-sparc/TODO Blue Swirl
2009-08-19 10:17   ` Artyom Tarasenko
2009-08-19 16:43     ` Blue Swirl [this message]
2009-08-20  9:44       ` Artyom Tarasenko
2009-08-20 19:15         ` Blue Swirl
2009-08-21  9:58           ` Artyom Tarasenko
2009-08-21 12:40             ` Artyom Tarasenko
2009-08-21 19:45               ` Blue Swirl
2009-08-21 21:01                 ` Artyom Tarasenko
2009-08-21 21:10                   ` Igor Kovalenko
2009-08-21 21:17                     ` Artyom Tarasenko
2009-08-22  6:51                   ` Blue Swirl
2009-08-22 12:40                     ` Artyom Tarasenko
2009-08-22 13:30                       ` Robert Reif
2009-08-22 17:25                         ` Artyom Tarasenko
2009-08-22 18:46                           ` Robert Reif
  -- strict thread matches above, loose matches on Subject: below --
2010-08-20 19:59 [Qemu-devel] target-sparc/TODO Artyom Tarasenko
2010-08-20 20:19 ` [Qemu-devel] target-sparc/TODO Blue Swirl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f43fc5580908190943y733cb56dvf35af9c9a325235a@mail.gmail.com \
    --to=blauwirbel@gmail.com \
    --cc=atar4qemu@googlemail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).