From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6722 invoked by alias); 16 Mar 2005 15:27:15 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 6641 invoked from network); 16 Mar 2005 15:27:10 -0000 Received: from unknown (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 16 Mar 2005 15:27:10 -0000 Received: from [10.12.1.178] (QNXWS7129 [10.12.1.178]) by nimbus.ott.qnx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G9AH1MKY; Wed, 16 Mar 2005 10:27:10 -0500 Message-ID: <423850D0.3020708@qnx.com> Date: Wed, 16 Mar 2005 16:39:00 -0000 From: Jeff Baker Reply-To: jbaker@qnx.com Organization: QNX Software Systems Ltd. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) MIME-Version: 1.0 To: Alan Modra CC: binutils@sources.redhat.com, Alex Rosenberg , Kumar Gala Subject: Re: [PATCH] Handle mtsprg and mfsprg properly for BookE References: <20050314041420.GJ13506@bubble.modra.org> In-Reply-To: <20050314041420.GJ13506@bubble.modra.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-03/txt/msg00446.txt.bz2 The IBM PPC440 doesn't support reading from the supervisory SPR's (you get garbage values back) - the mfsprg's won't be too useful. E.g.: running the following code (MSR.PR=0) (PVR=0x41020481): li %r7,-1 li %r8,-1 li %r6,1 mtspr 276,%r6 mfspr %r7,260 mfspr %r8,276 leaves R7 with a 1 and R8 with a 0. This is correct behaviour according to IBM. Alan Modra wrote: > On Sun, Mar 13, 2005 at 03:34:33PM -0800, Alex Rosenberg wrote: > >>On Mar 9, 2005, at 7:58 PM, Alan Modra wrote: >> >>>There remains the question of which spr number should be used by >>>privileged programs for read access to sprg4 through sprg7. Does the >>>non-privileged spr number work when privileged? I would think it >>>probably does, but I'm just guessing.. >> >>I think the documentation is the problem here. >> >>Originally, the user mode read-only SPRG were supposed to be referred >>to as USPRG. > > > Makes sense. Consistent with the spr numbering for USPRG0 too. > > I propose that gas adopt this syntax. ie. > > mtsprg and mtsprg[0-7] writes spr272..279 (as we currently do) > mfsprg and mfsprg[0-7] read the same regs as mtsprg > mfusprg0 reads spr256 (as we currently do) > Add new mfusprg[3-7] insns which read spr259..263 > Add a new mfusprg insn which reads spr256..263 >