qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Richard Henderson <rth@twiddle.net>
Cc: qemu-devel@nongnu.org, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH 01/10] target-s390: Move facilities bits to env
Date: Tue, 01 Oct 2013 17:54:37 +0200	[thread overview]
Message-ID: <524AF03D.5090308@suse.de> (raw)
In-Reply-To: <524AEFAB.8060701@twiddle.net>

On 10/01/2013 05:52 PM, Richard Henderson wrote:
> On 10/01/2013 08:48 AM, Alexander Graf wrote:
>> On 09/30/2013 09:15 PM, Richard Henderson wrote:
>>> On 09/30/2013 11:03 AM, Alexander Graf wrote:
>>>> On 09/23/2013 04:04 PM, Richard Henderson wrote:
>>>>> Rather than simply hard-coding them in STFL instruction.
>>>>>
>>>>> Signed-off-by: Richard Henderson<rth@twiddle.net>
>>>>> ---
>>>>>     target-s390x/cpu.c       |  3 +++
>>>>>     target-s390x/cpu.h       |  1 +
>>>>>     target-s390x/translate.c | 10 +++++-----
>>>>>     3 files changed, 9 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
>>>>> index 3c89f8a..ff691df 100644
>>>>> --- a/target-s390x/cpu.c
>>>>> +++ b/target-s390x/cpu.c
>>>>> @@ -181,6 +181,9 @@ static void s390_cpu_initfn(Object *obj)
>>>>>         env->cpu_num = cpu_num++;
>>>>>         env->ext_index = -1;
>>>>>
>>>>> +    env->facilities[0] = 0xc000000000000000ull;
>>>>> +    env->facilities[1] = 0;
>>>> Could we add CPU definitions along the way here? I'm fine with making z9 the
>>>> default CPU type, but we should make this explicit :).
>>> Certainly that's what we should do.  I just hadn't yet researched the
>>> currently correct way to do that.  I know there's some amount of out-of-date
>>> examples in the current source base.
>> I'll leave the answer to that to Andreas :).
> Can we leave that for a separate patch series then?

Just make sure you actually check for feature bits on every instruction 
(which I think you do, but the current code is way too magical to me to 
really understand it anymore) so that we can always implement a z900 cpu 
type later on.

>
>>>>> -    TCGv_i64 f, a;
>>>>> -    /* We really ought to have more complete indication of facilities
>>>>> -       that we implement.  Address this when STFLE is implemented.  */
>>>>> +    TCGv_i64 f = tcg_temp_new_i64();
>>>>> +    TCGv_i64 a = tcg_const_i64(200);
>>>>> +
>>>>>         check_privileged(s);
>>>>> -    f = tcg_const_i64(0xc0000000);
>>>>> -    a = tcg_const_i64(200);
>>>>> +    tcg_gen_ld_i64(f, cpu_env, offsetof(CPUS390XState, facilities[0]));
>>>>> +    tcg_gen_shri_i64(f, f, 32);
>>>> IMHO the facility list should be stored in DisasContext. That way we can check
>>>> whether we're generating code against the correct target.
>>> See patch 4.
>>>
>>> As for the code we generate here, does it really matter if we load the value
>>> from env, or have it encoded as a constant?  It still has to get stored to
>>> memory, so it's not like the TCG optimizer is going to do anything with the
>>> constant.
>> No, it only seemed more straight forward to me from a "single source of
>> information" point of view. But it really doesn't matter. Shifting in C seems
>> to be easier to read :).
> Fair enough.  I'll rearrange the order of the patches so that we can
> update STFL to use the DisasContext data.

Thanks :)


Alex

  reply	other threads:[~2013-10-01 15:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-23 14:04 [Qemu-devel] [PATCH 0/9] target-s390 tcg improvements Richard Henderson
2013-09-23 14:04 ` [Qemu-devel] [PATCH 01/10] target-s390: Move facilities bits to env Richard Henderson
2013-09-30 18:03   ` Alexander Graf
2013-09-30 19:15     ` Richard Henderson
2013-10-01 15:48       ` Alexander Graf
2013-10-01 15:52         ` Richard Henderson
2013-10-01 15:54           ` Alexander Graf [this message]
2013-10-01 15:56             ` Richard Henderson
2013-09-23 14:04 ` [Qemu-devel] [PATCH 02/10] target-s390: Implement STFLE Richard Henderson
2013-09-23 14:04 ` [Qemu-devel] [PATCH 03/10] target-s390: Add facilities bits and sets Richard Henderson
2013-09-23 14:04 ` [Qemu-devel] [PATCH 04/10] target-s390: Raise OPERATION exception for disabled insns Richard Henderson
2013-09-23 14:04 ` [Qemu-devel] [PATCH 05/10] target-s390: Implement SAM31 and SAM64 Richard Henderson
2013-09-23 14:04 ` [Qemu-devel] [PATCH 06/10] target-s390: Implement EPSW Richard Henderson
2013-09-23 14:04 ` [Qemu-devel] [PATCH 07/10] target-s390: Fix STIDP Richard Henderson
2013-09-30 18:13   ` Alexander Graf
2013-09-30 19:48     ` Richard Henderson
2013-10-01 15:52       ` Alexander Graf
2013-10-01 15:54         ` Richard Henderson
2013-09-23 14:04 ` [Qemu-devel] [PATCH 08/10] target-s390: Fix STURA Richard Henderson
2013-09-23 14:04 ` [Qemu-devel] [PATCH 09/10] target-s390: Implement LURA, LURAG, STURG Richard Henderson
2013-09-23 14:04 ` [Qemu-devel] [PATCH 10/10] target-s390: Implement ECAG Richard Henderson
2013-09-30 18:19 ` [Qemu-devel] [PATCH 0/9] target-s390 tcg improvements Alexander Graf

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=524AF03D.5090308@suse.de \
    --to=agraf@suse.de \
    --cc=afaerber@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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).