From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118331 invoked by alias); 7 Apr 2016 12:51:15 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 118274 invoked by uid 89); 7 Apr 2016 12:51:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=ground, danger, Allowing, rendered X-HELO: mail-wm0-f43.google.com Received: from mail-wm0-f43.google.com (HELO mail-wm0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 07 Apr 2016 12:51:03 +0000 Received: by mail-wm0-f43.google.com with SMTP id f198so24080622wme.0 for ; Thu, 07 Apr 2016 05:51:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=sA8v74j2NkXjOaNdEnzrv+OHvcbt9YTwBisgOEptREI=; b=LACQYzGIRrtfAK/PJCwcBVdpbvdW8XhOpDIMI8bMf2r6etNcvmXaLRAaUhZQDma35z il4gKMp/5nbT7OZsGwzp3npeUBcW3q5tK/5HAkJtKKLlFaKpSsvDeTFhQlilHQ8Tl23G kSZG5cQukaaJsMo5JXBd6S+Nf5xICbZ5fAGZeYx3jAUiSvqm9wdcgJZjY5XFYW41/l41 5xfqzkTiHA84PdtYJAEKYYiTP+FLNXYunNfULYsuSP3C8VPwTmYBQ4lnoag/ih6IWQxv 9suVmcp7ShQVmKpXOqbcSeq5AQCp48UF0t9Z5DFv1kuJB4zxwUs6Z0MCgAn8/jPUHHwl Fd7A== X-Gm-Message-State: AD7BkJJctU3Zn95DmKGdvn8GHs9mp6mGbBjo76fydTFH1aBnSwmpX6F055WCC4xAX/HARw== X-Received: by 10.28.53.134 with SMTP id c128mr30088164wma.10.1460033460776; Thu, 07 Apr 2016 05:51:00 -0700 (PDT) Received: from localhost (host81-140-212-51.range81-140.btcentralplus.com. [81.140.212.51]) by smtp.gmail.com with ESMTPSA id d123sm7839981wmd.9.2016.04.07.05.50.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Apr 2016 05:51:00 -0700 (PDT) Date: Thu, 07 Apr 2016 12:51:00 -0000 From: Andrew Burgess To: Claudiu Zissulescu Cc: "binutils@sourceware.org" , "noamca@mellanox.com" , Francois Bedard Subject: Re: [PATCH 1/6] gas/arc: Modify structure used to hold opcodes Message-ID: <20160407125045.GN25615@embecosm.com> References: <1459637470-30538-1-git-send-email-andrew.burgess@embecosm.com> <098ECE41A0A6114BB2A07F1EC238DE896617CF7D@DE02WEMBXB.internal.synopsys.com> <20160404090935.GD25615@embecosm.com> <098ECE41A0A6114BB2A07F1EC238DE896617D020@DE02WEMBXB.internal.synopsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <098ECE41A0A6114BB2A07F1EC238DE896617D020@DE02WEMBXB.internal.synopsys.com> X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00107.txt.bz2 * Claudiu Zissulescu [2016-04-04 14:43:15 +0000]: > > > > The problem with this is that as different variations of arc are added, > > > > then it is often more convenient to split instructions apart, so all the > > > > base ADD instructions are together, but, variants of ADD specific to one > > > > variation of arc are grouped with other instructions specific to that > > > > arc variant. The current data structures don't support this > > > > configuration of instructions. > > > > > > It may not be a good idea to overwrite the basic ARC ISA. Any ARC > > > customer can choose to have a different name than the standard ISA > > > names. Please can u reconsider this. > > > > I don't really understand what you are suggesting here, but ... > > > > > I do not see any reason why a > > > customer to use ADD mnemonic and not MYADD or something of a > > > sort. > > > > ... I think you're saying, change the ISA to work around limitation in > > the assembler :-/ That doesn't feel like a good answer, surely we > > should just adapt the assembler until it is flexible enough to handle > > whatever ISAs we need. > > What I am trying to say is that the ADD instruction should be as > described in ARC's Programmer Reference Manual, and we shouldn't > invent new mnemonics formats. Maybe, you pick wrongly the ADD > example, and you don't intend to overwrite the standard ADD > mnemonics format, which may break other tools as well (e.g. gcc). > As far as I understand, your patch is about the possibility of > describing a 3rd party instruction in separate groups, which is fine > by me. I think you're covering a lot of ground here, some of which I agree (strongly) with you on, but I don't think are what I'm proposing. Let's consider ARC700 for now, it has a specific set of ADD instructions defined. Now I'm _adding_ extension instructions. If one of my extensions instructions happened to be an addition instruction that took 4 registers, such that DST = SRC1 + SRC2 + SRC3, then this is clearly _not_ part of the core ARC700 architecture, but could live quite happily as an extension to ARC700. If I wanted to make an extension to ARC700 that actually rendered some of the core ARC700 instruction formats invalid, or gave them a different encoding then (a) I agree that's probably a bad idea, and (b) I would argue that stops being an extension to ARC700, and becomes a new architecture variant that is similar too, but is _not_ an extension of ARC700. What I want to do here is make an extension. Unless I teach GCC about the new instructions then GCC will never use them, but neither will anything produced by GCC fail to assemble, all the core instructions are still valid. > > > > > > Allowing the overwriting/addnotation of the standard ISA > > > mnemonics is opening a domain of pain. > > > > Could you clarify who you think will suffer this "domain of pain"? > > Mainly, the tool chain maintainer, which needs to keep an eye over > the compatibility between the GNU toolchain and the in-house ARC > toolchain (we are not alone ;)). Sure, but I suspect you guys will not be rushing to add nps support to your in house tools. If I (or anyone else) puts forward a patch that changes core arc700 functionality then that patch is broken. If the patch makes it into master then it needs fixing / reverting and more tests adding. As all these new instructions are extensions there should be no risk of compatibility problems. Of course we need to be careful in review, but that's always true :) > > > 1. Keep the current patch series, understanding that the ordering > > restriction still applies even across disjoint groups of > > instructions, and accepting that as a know danger area in the > > assembler. This would be my preferred solution. > > From my side, the idea of the patch is ok. You need to add the > explanation about keeping the ordering even if you use multiple > groups somewhere in your patch (probably in tc-arc.c). OK, that sounds like you're basically happy with the patch as is then. I'll update the patch series and post a new version here real soon. In the end I placed the comment into opcodes/arc-opc.c, at the head of the arc_opcodes table. I figured that anyone interested in adding new instructions would go there first, and any comment there was most likely to be found / read. I look forward to any further feedback you have. Thanks, Andrew