From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18593 invoked by alias); 16 Apr 2009 23:41:37 -0000 Received: (qmail 18585 invoked by uid 22791); 16 Apr 2009 23:41:36 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Apr 2009 23:41:32 +0000 Received: from anacreon.sc.intel.com (hpa@localhost [127.0.0.1]) (authenticated bits=0) by terminus.zytor.com (8.14.3/8.14.1) with ESMTP id n3GNdVq5016400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 16:39:31 -0700 Message-ID: <49E7C1B3.1070000@zytor.com> Date: Thu, 16 Apr 2009 23:41:00 -0000 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Masami Hiramatsu CC: Jim Keniston , Ingo Molnar , Ananth N Mavinakayanahalli , Andi Kleen , kvm@vger.kernel.org, Steven Rostedt , Frederic Weisbecker , Andrew Morton , Arnaldo Carvalho de Melo , systemtap-ml , LKML , Vegard Nossum , Avi Kivity , Roland McGrath Subject: Re: [PATCH -tip 3/6 V4.1] x86: instruction decorder API References: <49D4F4E6.6060401@redhat.com> <49D69BCA.8060506@redhat.com> <49D69F39.4010101@zytor.com> <49D6ABD1.7040704@redhat.com> <1239058135.5212.43.camel@localhost.localdomain> <49DA8857.8030607@zytor.com> <49E7BFDC.8040305@redhat.com> In-Reply-To: <49E7BFDC.8040305@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q2/txt/msg00292.txt.bz2 Masami Hiramatsu wrote: > > Hmm, I have an idea about instruction table. Usually, instruction tables > are encoded with code defined by each decoder/emulator. This method > will show their internal code directly, and is hard to maintain when > the opcode map is updated. Instead of that, I'd like to suggest using > the expressions in the opcode maps in a vender's genuine document (in > this case, Intel/AMD's manual) or www.sandpile.org for instruction > tables. > Yes, we discussed this at the Collab Summit. I think it's the only sane thing. > e.g. > > const insn_attr_t onebyte_attr_table[ATTR_TABLE_SIZE] = { > /* 0x00-0x0f */ > AT2(Eb,Gb), AT2(Ev,Gv), AT2(Gb,Eb), AT2(Gv,Ev), > AT2(AL,Ib), AT2(rAX,Iz), AT2(ES,i64), AT2(ES,i64), > AT2(Eb,Gb), AT2(Ev,Gv), AT2(Gb,Eb), AT2(Gv,Ev), > AT2(AL,Ib), AT2(rAX,Iz), AT2(CS,i64), AT(ESC), > ... > > Here, AT and AT2 macros are defined as follows: > I would suggest using an actual parser, rather than relying on cpp for this. The parser will be much more powerful, and will make it much easier to change data structure radically as we discussed. -hpa