Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!cmcl2!philabs!sbcs!debray
From: debray@sbcs.UUCP
Newsgroups: net.arch
Subject: Re: Addressing modes ("High Level" instructions)
Message-ID: <90@sbcs.UUCP>
Date: Fri, 7-Mar-86 08:36:30 EST
Article-I.D.: sbcs.90
Posted: Fri Mar  7 08:36:30 1986
Date-Received: Tue, 11-Mar-86 01:23:45 EST
References: <946@garfield.UUCP> <1417@sdcsvax.UUCP> <6777@boring.UUCP> <1476@lanl.ARPA> <78@cad.UUCP>
Organization: Computer Science Dept, SUNY@Stony Brook
Lines: 34

>                                       ...... What usually happens is
> that the 'high level' instruction is not as efficient as a sequence or
> loop of simpler instructions - or it is only efficient for a subset of
> its possible uses. 

The problem is mostly that it's harder to provide efficient implementations
for "High Level" instructions than it is for simple, "low level" ones.
Some time back, when working on a Prolog machine emulator on a Vax 780, we
found that it was _significantly less efficient_ to use a single
"Test, Set and Branch" instruction than it was to use three separate
instructions to test, set and branch respectively.  This seemed very
counterintuitive until we realized that instructions with 2 operands or
fewer had the operands decoded in hardware, while instructions with more
than 2 operands (e.g the "test-set-branch" instruction) had to go to
microcode for this.  I guess the extra instruction fetches for the case
using three separate instructions overlapped sufficiently due to pipelining
to give the hardware decoding an overwhelming edge.

On the other hand, I think that if efficient implementations could be
provided for some of these "High Level" instructions, it wouldn't be a bad
thing entirely.  In the same Prolog machine emulator, we looked at the
instruction sequences generated for various programs and coalesced a couple
of the more common instruction sequences to form "macro-instructions".  The
performance improvement from this was not unimpressive.  As far as generating
these complex instructions went, our compiler simply generated the old,
dumb code to begin with, then converted to the smarter code in one pass of
peephole optimization.
-- 
Saumya Debray
SUNY at Stony Brook

	uucp: {allegra, hocsd, philabs, ogcvax} !sbcs!debray
	arpa: debray%suny-sb.csnet@csnet-relay.arpa
	CSNet: debray@sbcs.csnet