Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.arch
Subject: HP RISC comments
Message-ID: <6504@utzoo.UUCP>
Date: Thu, 13-Mar-86 17:57:13 EST
Article-I.D.: utzoo.6504
Posted: Thu Mar 13 17:57:13 1986
Date-Received: Thu, 13-Mar-86 17:57:13 EST
Organization: U of Toronto Zoology
Lines: 63

The latest "Hewlett-Packard Journal" (Jan 1986 issue) has an article on
their new RISCish machine, which sounds moderately interesting.  It has
a relatively simple instruction set with pipelining at least semi-visible.
It does not have overlapping register windows, but its compilers make a
considerable effort to exploit its registers effectively; it sounds like
they have put a lot of work into optimization.  The most interesting part
of the article is a section entitled "Addressing RISC Myths", which spends
some time knocking down some of the standard objections.  A summary follows;
note that I'm summarizing HP's views rather than my own, although I agree
with most of it.

"An architected [i.e. microprogrammed] procedure call instruction is
necessary for efficient procedure calls."

Nope.  Intelligent compilation on a RISC architecture can do better, by
exploiting knowledge about register usage to produce non-worst-case code
customized to the particular situation.  One thing HP's compilers do is
to identify "leaf" procedures which don't call anything else, and use a
drastically streamlined calling convention for them.  Things like register
usage patterns of non-leaf procedures are also tailored for call speed.

"The simple instructions available in RISC result in significant
code expansion."

Nope.  Complex operations can be implemented in "millicode" (procedures
with extremely streamlined calling conventions).  Since this is normal
executable code, it can be written using normal tools, stored in ordinary
memory, and upgraded easily.  Also, since it's not bound by most of the
restrictions commonly found in microcode, it's much more practical to
use customized millicode to exploit detailed knowledge of specific
situations.  E.g., a bulk-move operation can exist in a number of different
versions so that the compiler can exploit knowledge of things like overlap,
alignment, size, etc., rather than forcing microcode to rediscover this
information at run time.

Also, complex instructions are seldom used; millicode costs only when
it is actually used.

"RISC machines must implement integer multiplication as successive additions."

Most integer multiplications in real programs are by small constants.  A
carefully-designed RISC machine with a good compiler can execute such
multiplications *faster* than a CISC which has only a fully-general multiply
instruction.  HP's new machine has a few specialized instructions to help,
notably "add" instructions which first shift one operand by 1-3 bits.  Given
these, "...multiplications by most constants with absolute values less than
1040 can be accomplished in fewer than five cycles".  The millicode routines
that handle more general cases still make an attempt to detect small
operands, resulting in an average multiplication time of 20 cycles,
comparable to a CISC iterative implementation.

"RISC machines cannot support commercial applications languages."

They mean COBOL, in particular.  Nope.  Most of the peculiar COBOL-oriented
instructions in, say, the 370 are very seldom executed even by COBOL code.
COBOL programs spend most of their time inside the operating system and
other subsystems.  Millicode is used for most low-level COBOL-oriented
operations, again with the compiler working hard to exploit knowledge of
the operands to pick the most streamlined millicode.  HP has also provided
some instructions to help the millicode.  The result is compact and fast.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry