From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:43284)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jcmvbkbc@gmail.com>) id 1QNKE7-0000jj-VW
	for qemu-devel@nongnu.org; Fri, 20 May 2011 03:34:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jcmvbkbc@gmail.com>) id 1QNKE7-0008S6-43
	for qemu-devel@nongnu.org; Fri, 20 May 2011 03:34:27 -0400
Received: from mail-bw0-f45.google.com ([209.85.214.45]:52339)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jcmvbkbc@gmail.com>) id 1QNKE6-0008S1-MT
	for qemu-devel@nongnu.org; Fri, 20 May 2011 03:34:27 -0400
Received: by bwz16 with SMTP id 16so3001238bwz.4
	for <qemu-devel@nongnu.org>; Fri, 20 May 2011 00:34:25 -0700 (PDT)
From: Max Filippov <jcmvbkbc@gmail.com>
Date: Fri, 20 May 2011 11:34:00 +0400
References: <1305671572-5899-1-git-send-email-jcmvbkbc@gmail.com>
	<1305671572-5899-10-git-send-email-jcmvbkbc@gmail.com>
	<4DD584C5.8080008@twiddle.net>
In-Reply-To: <4DD584C5.8080008@twiddle.net>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201105201134.04829.jcmvbkbc@gmail.com>
Subject: Re: [Qemu-devel] [PATCH 09/26] target-xtensa: add special and user
	registers
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Henderson <rth@twiddle.net>
Cc: qemu-devel@nongnu.org

> > +enum {
> > +    THREADPTR = 231,
> > +    FCR = 232,
> > +    FSR = 233,
> > +};
> > +
> >  typedef struct XtensaConfig {
> >      const char *name;
> >      uint64_t options;
> > @@ -109,6 +115,7 @@ typedef struct CPUXtensaState {
> >      uint32_t regs[16];
> >      uint32_t pc;
> >      uint32_t sregs[256];
> > +    uint32_t uregs[256];
> 
> Is it really worthwhile allocating 2k worth of space in the
> CPUState when only several of the slots are actually used?
> 
> I would think that it might be better to have a function to
> map between number to offset/register.  E.g.
> 
> int ur_offset(int ur)
> {
>     switch (ur) {
>     case THREADPTR:
>         return offsetof(CPUState, ur_threadptr);
>     case FCR:
>         return offsetof(CPUState, ur_fcr);
>     case FSR:
>         return offsetof(CPUState, ur_fsr);
>     }
>     return -1;
> }
> 
> where the individual slots are allocated by hand in the
> CPUState.  The fact that they'll be named in the struct
> will also make it easier to dump the value inside gdb and
> see what the individual values are.

User registers represent TIE states that may appear in custom xtensa configurations. I'd better change RUR and WUR so that they can access all user registers but warn on those not defined globally or in the CPUEnv::config.
Is it OK?

Thanks.
-- Max