Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!decwrl!labrea!polya!andy
From: andy@polya.STANFORD.EDU (Andy Freeman)
Newsgroups: comp.arch
Subject: Re: Auto-shifted registers
Message-ID: <2078@polya.STANFORD.EDU>
Date: 24 Feb 88 20:20:21 GMT
References: <1370@vaxb.calgary.UUCP> <188@granite.dec.com>
Reply-To: andy@polya.stanford.edu (Andy Freeman)
Organization: Stanford University
Lines: 21

In article <188@granite.dec.com> jmd@granite.UUCP (John Danskin) writes:
>In article <1370@vaxb.calgary.UUCP> radford@calgary.UUCP (Radford Neal) writes:
>>[Radford Neal suggests that the ability to shift a register's value
>> in any kind of register reference might be a good thing.]
>Add with shift instructions can be very nice. They speed address
>calculations, and can be used as part of a multiply by small constant.
>.... However, based on my own coding practice, it isn't worth giving
>up two instruction bits for the capability. Instruction bits are
>incredibly useful things, and it is hard enough to stay at 32 bits
>without 'using just a couple more bits' for something that isn't going
>to be used even every tenth cycle.

The MIPS-X compute instructions, which are all register to register,
use 12 bits to determine the operation.  There are 17 of them (79 if
you count the shift instructions separately - MIPS-X uses 7 bits to
encode the shift amount but more compact schemes exist).  Now, it may
be that a more compact encoding would slow the chip down more than
``shift any register value'' would help, but that's different than
saying that 32 bits is a tight fit for register reference instructions
in a load-store architecture.

-andy