From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15361 invoked by alias); 15 Jan 2002 12:25:33 -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 15311 invoked from network); 15 Jan 2002 12:25:30 -0000 Received: from unknown (HELO mill.nexus.co.uk) (62.3.66.201) by sources.redhat.com with SMTP; 15 Jan 2002 12:25:30 -0000 Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by mill.nexus.co.uk with esmtp (Exim 3.33 #1 (Debian)) id 16QSeZ-00042K-00; Tue, 15 Jan 2002 12:25:23 +0000 Subject: Re: GAS: Handling option parsing for ARM co-processor extensions From: Phil Blundell To: Richard.Earnshaw@arm.com Cc: binutils@sources.redhat.com In-Reply-To: <200201151212.MAA14894@cam-mail2.cambridge.arm.com> References: <200201151212.MAA14894@cam-mail2.cambridge.arm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: Tue, 15 Jan 2002 05:21:00 -0000 Message-Id: <1011097523.15428.2.camel@mill> Mime-Version: 1.0 X-SW-Source: 2002-01/txt/msg00261.txt.bz2 On Tue, 2002-01-15 at 12:12, Richard Earnshaw wrote: > Well, not really, since AFAICT from the Cirrus web pages, Maverick is just > a co-processor extension on a CPU. There's nothing much to tie it to a > particular processor, so using -mmaverick to imply a particular CPU looses > flexibility. Um, yeah, I didn't make that very clear. I meant that you would end up with "-marmv4 -mmaverick" or something like that, along the lines of the "-marmv3 -mfpa10" that we have now. XScale was a dumb thing to pick as an example. > Incidentally, I'm a bit concerned about -mxscale as a processor. From the > documents I've read XScale seems to be more of a specification for an > architecture than a single implementation. Yes, I think that's right. I'm not sure that the distinction is particularly important right now, though. p.