This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -tip 3/6 V4.1] x86: instruction decorder API
- From: Masami Hiramatsu <mhiramat at redhat dot com>
- To: "H. Peter Anvin" <hpa at zytor dot com>
- Cc: Jim Keniston <jkenisto at us dot ibm dot com>, Ingo Molnar <mingo at elte dot hu>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Andi Kleen <andi at firstfloor dot org>, kvm at vger dot kernel dot org, Steven Rostedt <rostedt at goodmis dot org>, Frederic Weisbecker <fweisbec at gmail dot com>, Andrew Morton <akpm at linux-foundation dot org>, Arnaldo Carvalho de Melo <acme at redhat dot com>, systemtap-ml <systemtap at sources dot redhat dot com>, LKML <linux-kernel at vger dot kernel dot org>, Vegard Nossum <vegard dot nossum at gmail dot com>, Avi Kivity <avi at redhat dot com>, Roland McGrath <roland at redhat dot com>
- Date: Tue, 21 Apr 2009 20:17:57 -0400
- 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> <1239926776.5883.17.camel@dyn9047018094.beaverton.ibm.com> <49E7C87E.8000202@zytor.com>
H. Peter Anvin wrote:
> Jim Keniston wrote:
>> It looks like AT2(Ev,Gv) would yield the same bits as AT2(Gv,Ev). It'd
>> be nice not to lose the operand-order information. And we'd have to
>> make clear whether which notation we're using -- src,dest as in the gnu
>> assembler, or dest,src as in the AMD (and Intel?) manuals.
>>
>
> Since the information would come from the manuals, I would recommend
> following them (dst first.)
>
Hi Peter and Jim,
Now what I'm doing is making opcode tables like this.
Table: 1-byte opcode
Alias: none
00: ADD Eb,Gb
01: ADD Ev,Gv
02: ADD Gb,Eb
03: ADD Gv,Ev
04: ADD AL,Ib
05: ADD rAX,Iz
06: PUSH ES (i64)
07: POP ES (i64)
08: OR Eb,Gb
09: OR Ev,Gv
0a: OR Gb,Eb
0b: OR Gv,Ev
0c: OR AL,Ib
0d: OR rAX,Iz
0e: PUSH CS
0f: 2-byte escape
...
and a parser script which parses them into,
const insn_attr_t primary_table[INAT_TABLE_SIZE] = {
[0x04] = INAT_IMM(IMM_SIZE_BYTE)
[0x05] = INAT_IMM(IMM_SIZE_VWORD32)
[0x0c] = INAT_IMM(IMM_SIZE_BYTE)
[0x0d] = INAT_IMM(IMM_SIZE_VWORD32)
[0x0f] = INAT_ESC(IMM_ESC_2BYTE)
...
(note, instructions which has no attributes for decoder, are just ignored)
By the way, I'm worried about legal things of Intel's instruction
encoding expressions. Would you think there is any problem if we
have those tables in the kernel tree?
Thanks,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com