Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!umnd-cs!umn-cs!herndon
From: herndon@umn-cs.UUCP
Newsgroups: comp.sys.m68k,comp.sys.intel
Subject: Re: Recent Motorola ad seen in Byte
Message-ID: <1538@umn-cs.UUCP>
Date: Tue, 5-May-87 14:58:59 EDT
Article-I.D.: umn-cs.1538
Posted: Tue May  5 14:58:59 1987
Date-Received: Thu, 7-May-87 03:03:29 EDT
References: <930@intsc.UUCP> <1517@ncr-sd.SanDiego.NCR.COM> <932@intsc.UUCP> <365@winchester.UUCP>
Distribution: comp
Organization: University of Minnesota, Minneapolis
Lines: 53
Xref: utgpu comp.sys.m68k:427 comp.sys.intel:207
Summary: Non-Orthogonal Instruction Sets

In article <365@winchester.UUCP>, mash@mips.UUCP (John Mashey) writes:
> In article <274@fornax.uucp> chapman@fornax.uucp (John Chapman) writes:
> > ...Discussion of dedicated registers for string ops...
> >
> >Why is it necessary to have full generality for these instruction
> >operands?  You know in advance what you will be using a calculation
> >result for so do it in the register it needs to be in. You have all
> >the other registers to do what you want with so why is it a problem
> >that (for example) the vax uses low numbered registers for string
> >operands? What exactly does it prevent you from doing?
> 
> In general, it's an OK tradeoff.  What it does make harder is the use
> of more serious optimizing compilers.
>     . . . . . . . . . . . . . . . . . . . .  Compiler writers have
> always disliked things like:
> 	register pairs needed for certain operations
> 	special registers used by some instructions
> 	unnecesarily assymetric register sets
> Again: not a disaster, and maybe a correct tradeoff, given all of the
> other assumptions alrady builtin, but not what one would like.

  I'll second John on this.  Having used an early Intermetrics
optimizing compiler for the 8086, I truly respect those people
who had to write the optimizer for it.  In spite of very good
register allocation/instruction optimizations, there were so many
"gotcha's" in the processor that some of them inevitably got
through.  Among them were (from memory):
  1) AX was the only register usable with I/O instructions, and
     many instructions insisted on having one operand in AX,
     e.g., XLAT.
  2) BX was the only register usable as a stack offset
  3) CX always held the count for shift and string operations.
  4) DX got high-order results from the multiply, one of the
     multiply ops had to be in AX, and the low-order result
     was in AX.  (Sometimes this clobbered something.)
  5) Some of the instructions did not permit segment over-ride
     prefixes (still executed, but the instruction didn't work as
     anticipated.)
  6) Not all instructions set the condition codes as might be
     expected.
  While any one of these can easily (maybe) be anticipated, the
effect of so many is to overwhelm the poor optimizer writer.
EVERY SINGLE REGISTER on the 80X86 series has one or more special 
uses.  I readily admit that only one of the problems we found
was not documented in the processor manuals (the POPF instruction
had problems), but having soooooooooo many exceptions made the
advertising concept of "8086 general registers" an oxymoron.

-- 
Robert Herndon				Dept. of Computer Science,
...!ihnp4!umn-cs!herndon		Univ. of Minnesota,
herndon@umn-cs.ARPA			136 Lind Hall, 207 Church St. SE
herndon.umn-cs@csnet-relay.ARPA		Minneapolis, MN  55455