From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23091 invoked by alias); 19 Mar 2012 15:50:30 -0000 Received: (qmail 23079 invoked by uid 22791); 19 Mar 2012 15:50:29 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Mar 2012 15:49:58 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 1974F1C657C; Mon, 19 Mar 2012 11:49:58 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aBLdD8i1eIZj; Mon, 19 Mar 2012 11:49:58 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D458B1C6549; Mon, 19 Mar 2012 11:49:57 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 74641145615; Mon, 19 Mar 2012 08:49:41 -0700 (PDT) Date: Mon, 19 Mar 2012 15:50:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: RFC: merge std-operator.def and ada-operator.def? Message-ID: <20120319154941.GX2853@adacore.com> References: <1331940061-10739-1-git-send-email-brobecker@adacore.com> <20120319084514.GA29240@host2.jankratochvil.net> <20120319153347.GW2853@adacore.com> <20120319153939.GA23668@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120319153939.GA23668@host2.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00704.txt.bz2 > I am not so in favor of it. Anything than can be made more specific with the > same user-visible functionality should be made so. It simplifies maintenance. > This is the exact reason why I wanted to mark them as OP_ADA_*. > > I understand putting the code into generic parts is easier for you. I am not doing this because it makes it easier for me; what started this was the realization that some of the code looks unnecessarily complex, or not even necessary at all. While I agree with you on the general principle that language-specific features should be clearly marked, in this case, I draw from Tom and I's experience with the type handling and the language vector. Part of the language vector and the associated complexity would be unnecessary if Ada was more standard, rather than some side-entity that needs to be plugged into the core system. That being said, it's not terribly important to me that some opcodes are going to be labeled "ADA". It's going to be a bit of a pain for a while to keep AdaCore's sources in sync, but not difficult. So let's not discuss this too much and decide what we want to do: 1. Do we want to go with the propose patch series (merging the def files, and then simplifying a bit the code afterwards)? 2. Do we want to rename the Ada opcodes? I can do that as a third patch, for instance. -- Joel