From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23148 invoked by alias); 9 Mar 2005 11:43:55 -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 22567 invoked from network); 9 Mar 2005 11:43:32 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org with SMTP; 9 Mar 2005 11:43:32 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id j29Bdapd024953; Wed, 9 Mar 2005 11:39:36 GMT Received: from pc960.cambridge.arm.com (localhost.localdomain [127.0.0.1]) by pc960.cambridge.arm.com (8.12.8/8.12.8) with ESMTP id j29Bdgrg014593; Wed, 9 Mar 2005 11:39:42 GMT Received: (from rearnsha@localhost) by pc960.cambridge.arm.com (8.12.8/8.12.8/Submit) id j29BdggO014591; Wed, 9 Mar 2005 11:39:42 GMT X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha set sender to rearnsha@gcc.gnu.org using -f Subject: Re: PATCH: Additional Thumb instructions for ARMv6K From: Richard Earnshaw To: Zack Weinberg Cc: binutils@sources.redhat.com In-Reply-To: <87u0nlhb09.fsf@codesourcery.com> References: <87u0nlhb09.fsf@codesourcery.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: GNU Message-Id: <1110368381.14453.38.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 Date: Wed, 09 Mar 2005 11:43:00 -0000 X-SW-Source: 2005-03/txt/msg00263.txt.bz2 On Wed, 2005-03-09 at 01:19, Zack Weinberg wrote: > ARMv6K adds five new Thumb instructions. This patch adds assembler > support for them. > > The only possibly problematic part of this patch is the NOP changes. > One of the new instructions is a preferred opcode for NOP (which has > historically been done with "mov r8,r8"); I changed both what you get > if you explicitly write "nop" and the opcode used for alignment in > code sections, when (cpu_variant & ARM_EXT_V6K). This *might* cause > problems for existing code. Please advise. Hmm, I think we've got a problem here. Gas is normally configured to default to the pseudo CPU 'all' which permits instructions from any architecture. That means that unless the user has explicitly set a cpu (or gcc has done it for you) then the new nop will match rather than the old (because of the way the selection logic works as a bit-field and mask). I'm not sure that's desirable because it might break existing code that did not expect to have to supply a CPU option. [You probably won't have noticed this because the basic thumb instruction set test in gas isn't a dump test -- probably something else that should be fixed. In fact, I think all the thumb tests in gas use an explicit -mcpu= argument.] However, we might have to break the -mcpu=all assumption anyway when we come to adding build attributes for the EABI; we don't want to end up marking all objects as requiring an ARMv6 (or higher) core simply because the user didn't set something explicitly on the command line. One partial solution is to pick some architecture (