From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-8872-listarch-gdb=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 27129 invoked by alias); 12 May 2002 15:41:23 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 27122 invoked from network); 12 May 2002 15:41:22 -0000
Received: from unknown (HELO localhost.redhat.com) (24.112.240.27)
  by sources.redhat.com with SMTP; 12 May 2002 15:41:22 -0000
Received: from cygnus.com (localhost [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP
	id 91E8B3E08; Sun, 12 May 2002 11:41:31 -0400 (EDT)
Message-ID: <3CDE8D2B.1060706@cygnus.com>
Date: Sun, 12 May 2002 08:41:00 -0000
From: Andrew Cagney <ac131313@cygnus.com>
User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Richard.Earnshaw@arm.com
Cc: gdb@sources.redhat.com
Subject: Re: ARM and virtual/raw registers
References: <200205121525.QAA02703@cam-mail2.cambridge.arm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-05/txt/msg00127.txt.bz2

>  However, in this situation, 
>> > pseudo_rengo("r0") != regcache_regno("r0"), yet we effectively have
>> > 
>> > REGSITER_RAW_SIZE (pseudo_regno ("r0")) 
>> > and
>> > REGISTER_RAW_SIZE (regcache_regno ("r0"))
> 
>> 
>> Sorry, I still don't understand.  
> 
> 
> In my view of things, the domain of the result returned by pseudo_regno() 
> is
> 0..Num_pseudos,

Pseudo-registers occupy the space:

[NUM_REGS .. NUM_REGS+NUM_PSEUDO_REGS)

there isn't an overlap.

As I said, I'd like to have strongly typed ``struct pseudoreg *'' and 
``struct rawreg *''.  In the mean time, this numeric separation is the 
onlything we have.

> and the domain of regcache_regno() is
> 
> 0..NUM_REGS
> 
> But we have cases where the two functions return a different number for 
> the same register; more precisely, we might encounter the situation where
> 
> pseudo_regno ("int_reg0") == regcache_regno ("float_reg5")

That isn't correct.

Andrew