Re: LuxAsm's progress
From: C (blackmarlin_at_asean-mail.com)
Date: 03/29/04
- Previous message: Herbert Kleebauer: "Re: Hey Mr. Hyde!"
- In reply to: Frank Kotler: "Re: LuxAsm's progress"
- Next in thread: THAW: "Re: Hey Mr. Hyde!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 29 Mar 2004 09:55:54 -0800
Frank Kotler <fbkotler@comcast.net> wrote in message news:<40647708.7030605@comcast.net>...
> C wrote:
>
> > The only problem is that typing in all the
> > opcodes is _really_ tedious, I have only a the first few dozen
> > integer operations for testing though I add a few more each day.
>
> Nasm has "insns.dat" which is processed by "insns.pl" into several (C...
> the language) formats. A little tweaking to "insns.pl" would probably
> produce an asm format LuxAsm could use. Gas and Yasm, among others, have
> instuction lists, too (including x86-64?). A suggestion was made on the
> nasm-devel list that this stuff could be extracted directly from the
> Intel docs, too (both into code, and into the docs). Don't spend too
> much of your time doing tedious typing! Probably need a few "for test"
> (and to determine the format we want!), but doing it all "by hand" can
> probably be avoided...
Well, each instruction itself only takes up about a line (using a macro)
and the instructions are grouped based on their encoding format(s). So
adding a new instruction often can be done in only a couple of seconds
using cut-paste-modify. The problem comes in writing the procedure to
convert the encoding into the byte format. I have written encodings
for the just about everying which does not either require the FPU or
0F prefix, this should be enough to test the assembler and the
remainder, as you say, can wait for later.
As for the format, the Parse module is virtually completely independent
of the Encode_Instruction module and therefore, provided the interface
remains the same, replacing either should be easy.
I have had a peek as insns.dat; the information contained is similar
to what I am using so mechanical transformation may be possible, though
I suspect typing it in directly (with a touch of automated search and
replace) would be quicker than rewriting the script and modifying the
internals on the Encode_Instruction module -- especailly for the ADC/
ADD/SUB/... general instructions which Luxasm just classes as type
Encode.GENERAL and groups together in one section.
As for extracting the data from the Intel docs, that I suspect would
be more useful for documentation than code -- adding hyperlinks
across the documentation should be relitively simple; but you are
right in that doing so would only sidetrack me from that main code.
I am going to try and fish out the code for SAss, there is a nice
algorithm for generating ModRM/SIB bytes which, if I remember
correctly, uses a very similar data format to what I have now.
That should save a little time.
C
2004-03-29
PS: The current macro list is something like...
opcode <name>, <base>, <format>, <mods | version>, <architecture>
eg. opcode "ADD", 0x00, Encode.GENERAL, 0, Arch.IA32
opcode "RET", 0xC3, Encode.CODE, 0, Arch.IA32
opcode 0, 0xC2, Encode.CODE_IW, 0, Arch.IA32
opcode "PUSHAD", 0x60, Encode.CODE, Mod.M32 | 3, Arch.IA32
opcode "PUSHA", 0x60, Encode.CODE, Mod.M16 | 2, Arch.IA32
- Previous message: Herbert Kleebauer: "Re: Hey Mr. Hyde!"
- In reply to: Frank Kotler: "Re: LuxAsm's progress"
- Next in thread: THAW: "Re: Hey Mr. Hyde!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
