Date: Mon, 23 Jun 2003 13:51:06 +0300 (EET DST)
From: Esa A E Peuha <peuha AT cc DOT helsinki DOT fi>
Sender: peuha AT sirppi DOT helsinki DOT fi
To: djgpp-workers AT delorie DOT com
Subject: Re: Bugs in unassmbl.c
In-Reply-To: <200306192256.h5JMu1px028229@speedy.ludd.luth.se>
Message-ID: <Pine.OSF.4.51.0306231325590.31938@sirppi.helsinki.fi>
References: <200306192256 DOT h5JMu1px028229 AT speedy DOT ludd DOT luth DOT se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Fri, 20 Jun 2003 ams AT ludd DOT luth DOT se wrote:

> This seems right too (after the patch i. e.), according to the Intel
> manual, although it's confusing with 16, 24, 32... matching 0x8a,
> 0x8b, 0x8c.

How do 0x8a and rest relate to the actual opcodes?  The numbers used in
the sources are the standard esc codes: if the first two bytes of the
opcodeare (in binary notation) 11011aaa bbcccddd, then the esc code is
aaaccc; if bb is not 11, then the esc code determines the instruction
(except for the memory operand); if bb is 11, then the esc code and ddd
together determine the instruction.

> (Perhaps "00... 08... 16..." should be changed to "00, opcodes
> 0x88... 08, opcodes 0x89... 16, opcodes 0x8a..."?)

I don't think so, at least not until you explain why your notation is
better than the current one.

-- 
Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/