From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3551 invoked by alias); 15 Jul 2002 17:46:30 -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 3333 invoked from network); 15 Jul 2002 17:46:27 -0000 Received: from unknown (HELO mms3.broadcom.com) (63.70.210.38) by sources.redhat.com with SMTP; 15 Jul 2002 17:46:27 -0000 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7)); Mon, 15 Jul 2002 10:46:22 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA00387; Mon, 15 Jul 2002 10:46:23 -0700 (PDT) Received: from dt-sj3-118.sj.broadcom.com (dt-sj3-118 [10.21.64.118]) by mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id g6FHkMER018655; Mon, 15 Jul 2002 10:46:23 -0700 (PDT) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id KAA02285; Mon, 15 Jul 2002 10:46:20 -0700 (PDT) To: rsandifo@redhat.com cc: "Thiemo Seufer" , gcc-patches@gcc.gnu.org, binutils@sources.redhat.com Subject: Re: RFC & patch: Rework MIPS command-line handling References: <20020714172200.GH19894@rembrandt.csv.ica.uni-stuttgart.de> From: cgd@broadcom.com Date: Mon, 15 Jul 2002 10:47:00 -0000 In-Reply-To: rsandifo@redhat.com's message of "Mon, 15 Jul 2002 10:13:47 +0000 (UTC)" Message-ID: MIME-Version: 1.0 X-WSS-ID: 112DD5E4301765-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00331.txt.bz2 At Mon, 15 Jul 2002 10:13:47 +0000 (UTC), "Richard Sandiford" wrote: > Thiemo Seufer writes: > > I agree, -mipsN should be an alias for the equivalent -march=FOO. > > Please note that the -mipsN options should IMHO be obsoleted: > > > > - They are asymmetric because all of them can be replaced by > > -march=FOO, but there are -march=FOO without -mipsN equivalents > > I'd guess the ISA levels are more well known than the processors we're > associating them with, so there's probably no harm in keeping them as > aliases, but... I actually think it's important to keep them. In general, it's quite desriable to be able to say, for instance: "will run on any MIPS N CPU, but optimized for this particular CPU." where, say, N == 1. historically, the first part of that has been caused by -mips1 (for N == 1), and people I think have come to expect that. I do think it's reasonable and probably desirable to support (can you hear the maniacal laughing, too?): -march=mips1 (in the NWO would that be mipsisa1. 8-) > > - As CPU aliases they can allow opcodes which aren't available > > on other ISA-conforming CPUs. > > Not sure what you mean. Do you have any examples? If the CPU aliases for the ISA aren't the minimal set for the ISA, that sounds like a very good reason for somebody to go off and do something better, i.e., create "actual ISA" definitions. I believe that at least mipsisa32 and mipsisa64 -- ISAs which are really ISAs in the code, rather than being CPUs -- are correct. 8-) > > Strictly speaking, MIPS 32 code isn't conforming to o32 ABI. > > The same should be true for MIPS IV opcodes in n32 code. > > Hmm... not sure why, Because the o32 ABI specification was defined as MIPS I only. I.e., MIPS I instructions only and EF_MIPS_ARCH == 0. It's a definitional thing. 8-) The notion that a bunch of us like more is something like: "ABI means file format, calling conventions, etc. Orthogonal to that is the ISA level, and the ISA level is easy to check via EF_MIPS_ARCH." I think that's a much more useful way to think about things given the plethora of ISAs. And, in that view, -mabi=foo probably shouldn't change the ISA (and definitely shouldn't downgrade it). cgd