Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site spar.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!spar!freeman
From: freeman@spar.UUCP (Jay Freeman)
Newsgroups: net.arch,net.micro,net.micro.pc,net.micro.68k
Subject: Re: X86 / 68XXX
Message-ID: <292@spar.UUCP>
Date: Wed, 5-Jun-85 15:25:22 EDT
Article-I.D.: spar.292
Posted: Wed Jun  5 15:25:22 1985
Date-Received: Mon, 10-Jun-85 01:07:10 EDT
References: <426@oakhill.UUCP> <8745@microsoft.UUCP>
Reply-To: freeman@max.UUCP (Jay Freeman)
Organization: Schlumberger Palo Alto Research, CA
Lines: 19
Xref: linus net.arch:1151 net.micro:9435 net.micro.pc:3887 net.micro.68k:829

In article <1005@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes:

>A major problem with the 286 (and I guess the 386 too, though I haven't
>seen it yet, only the fragmentary descriptions in this newsgroup) is in the
>number of bits available in the instructions themselves for addressing
>data.  This is the primary addressing problen.  The 8086 family has a
>maximum of 16 bits of address for most instructions.

There is no reason that a CPU is limited to one fetch to get the operands
for an instruction.  Many 8- and 16-bit CPUs, including the 8086, have
instructions requiring far more than 8- or 16-bits of operand.  

>                [If you really want an appreciation for the complexity
>of the instruction set, try designing an assembler for it!  Even when you
>think you understand the instruction encoding, you may suddenly discover
>that there are two instructions that don't quite fit...]

Concur.
-- 
Jay Reynolds Freeman (Schlumberger Palo Alto Research)(canonical disclaimer)