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
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

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/

- Raw text -