Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!petsd!peora!jer
From: jer@peora.UUCP (J. Eric Roskos)
Newsgroups: net.arch,net.micro,net.micro.pc,net.micro.68k
Subject: Re: X86 / 68XXX
Message-ID: <1030@peora.UUCP>
Date: Fri, 7-Jun-85 08:33:24 EDT
Article-I.D.: peora.1030
Posted: Fri Jun  7 08:33:24 1985
Date-Received: Sat, 8-Jun-85 03:55:14 EDT
References: <426@oakhill.UUCP> <8745@microsoft.UUCP>
Organization: Perkin-Elmer SDC, Orlando, Fl.
Lines: 23
Xref: watmath net.arch:1340 net.micro:10700 net.micro.pc:4171 net.micro.68k:884

freeman@spar.UUCP (Jay Freeman at Schlumberger Palo Alto Research, CA),
commenting on my statement that the major problem with 8086 addressing is
not the "maximum segment size", but rather the number of address bits in
the instructions, writes:

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

I'm somewhat confused as to what this has to do with my original comment.
What I meant was that, in the definition of the instruction set (which
doesn't have anything to do with the number of fetches required to get the
operands in any particular CPU implementation), the address fields are at
most 16 bits long. (This does not include, of course, the small number of
"long" address operands, such as the intersegment call and jump
instructions.)
-- 
Full-Name:  J. Eric Roskos
UUCP:       ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
US Mail:    MS 795; Perkin-Elmer SDC;
	    2486 Sand Lake Road, Orlando, FL 32809-7642

	    "Zl FB vf n xvyyre junyr."