From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26470 invoked by alias); 13 Jul 2002 07:35:17 -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 26077 invoked from network); 13 Jul 2002 07:34:01 -0000 Received: from unknown (HELO mms1.broadcom.com) (63.70.210.58) by sources.redhat.com with SMTP; 13 Jul 2002 07:34:01 -0000 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Sat, 13 Jul 2002 00:33:33 -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 AAA26557; Sat, 13 Jul 2002 00:34:00 -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 g6D7Y0ER009216; Sat, 13 Jul 2002 00:34:00 -0700 (PDT) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id AAA14545; Sat, 13 Jul 2002 00:33:58 -0700 (PDT) To: rsandifo@redhat.com cc: gcc-patches@gcc.gnu.org, binutils@sources.redhat.com Subject: Re: RFC & patch: Rework MIPS command-line handling References: From: cgd@broadcom.com Date: Sat, 13 Jul 2002 00:40:00 -0000 In-Reply-To: rsandifo@redhat.com's message of "Fri, 12 Jul 2002 17:04:01 +0000 (UTC)" Message-ID: MIME-Version: 1.0 X-WSS-ID: 1131084768783-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00277.txt.bz2 At Fri, 12 Jul 2002 17:04:01 +0000 (UTC), "Richard Sandiford" wrote: > - GAS and GCC didn't have quite the same -march arguments. For > example, GCC accepts -march=r4kc, but GAS insists on -march=4kc. > To avoid that sort of thing in future, I've written a function > that tries all the variations, using a table of just the > "canonical" names. accepting "r4kc" etc., would appear to be a bug w/ with GCC implementation. I wouldn't suggest propagating it, since it does cause confusion with "r4000" (which people think of as 'r4k'). > I'd prefer to choose the default CPU in configure: that way, we'd > get a compile-time error over missing entries, plus we can use globs. yay. > Before 2.12, we only set EF_MIPS_ABI when -mabi was given on > the command line. Since EF_MIPS_ABI is a GNU extension, the > onus seems to be on proving that it's safe to use it by default, > rather than the other way about. So the patch uses NO_ABI as > the default for all configurations, but leaves open the possibility > of setting the default to something else on a per-configuration > basis. So, in the absence of EF_MIPS_ABI, what is a sane, compact code fragment which will reliably determine which ABI is in use? It's important to have such a thing. There's still an argument to be had which says "nobody else is doing the right thing here, if we need binary ABI marking we should do it and encourage others to follow suit," e.g. has happened w/ the arch markings. some specific comments about the patch: i didn't really look carefully at the gas changes. I suspect that they'll break our firmware like the last set of ABI-related changes did, but, well, assuming they pass all of the existing test cases (w/ the one changed as you did), it shouldn't be too bad. 8-) > ! @item -mips32 > ! @opindex mips32 > ! Equivalent to @samp{-march=r4kc}. > > ! @item -mips64 > ! @opindex mips64 > ! Equivalent to @samp{-march=r5kc}. again, the proper names of these cores as far as i'm aware (see MIPS web pages) are MIPS32 4Kc and MIPS64 5Kc. I.e., the 'r' is really truly incorrect here, unlike for the R4000 which was really called the R4000. (same for 20kc, btw.) > + /* This array must have the same order as enum processor_type. */ > + static const struct mips_processor mips_processors[] = { > + { "default", 0, 1 }, > + { "r3000", "_R3000", 1 }, > + { "r3900", "_R3900", 1 }, > + { "r6000", "_R6000", 2 }, > + { "r4000", "_R4000", 3 }, > + { "vr4100", "_R4100", 3 }, > + { "vr4300", "_R4300", 3 }, > + { "r4600", "_R4600", 3 }, > + { "r4650", "_R4650", 3 }, > + { "vr5000", "_R5000", 4 }, > + { "r8000", "_R8000", 4 }, > + { "r4kc", "_R4KC", 32 }, > + { "r5kc", "_R5KC", 64 }, > + { "r20kc", "_R20KC", 64 } > + }; OK, assuming that i'm seeing all of the uses of these, disagree on a couple of grounds: * some of these are things which implementations (i.e., existing systems) may have already come to define. IMO they need more letters. * we should also be providing a predefine for tune. Ideally what i'd like to see is something like: _MIPS_ARCH=_PROCESSOR_FOO _MIPS_TUNE=_PROCESSOR_BAR then internally define _PROCESSOR_FOO and _PROCESSOR_BAR to have unique numbers internally and only add as defines the ones which are used. So long as you avoid 0, this allows you to do useful, sane things, e.g.: #if ((_MIPS_ISA == 4) || (_MIPS_ARCH == _PROCESSOR_SPECIAL)) && \ (_MIPS_TUNE != _PROCESSOR_BROKEN) and: switch (_MIPS_TUNE) { #ifdef _PROCESSOR_X case _PROCESSOR_X: asm(...); break; #endif #ifdef _PROCESSOR_Y case _PROCESSOR_Y: asm(...); break; #endif default: unoptimized_code(); break; } Personally, I find that to be a prettier and _much much more useful_ idiom than something _MIPS_ARCH_FOO, _MIPS_TUNE_FOO. Finally, for the 'print a number but don't necessarily say what it is' crowd, it lets you encode the arch/tune values in the program in a fail-safe way that a code builder w/ the compiler source can later use (e.g. after a bug report) to figure out which arch/tune was used. (can't do that with _MIPS_ARCH_FOO, since what if the one that's define is one you don't know about. with something like described above, it's always an integer.) In any case, you really do need longer names for most of those IMO. > + /* Return true if GIVEN is the same as CANONICAL, or if it is CANONICAL > + with a final "000" replaced by "k". Ignore case. Oi, this is really going to exacerbate 4kc vs r4k problems if you allow the 4kc to be called the r4kc! I may have missed some things, too. 8-) chris