Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!uw-beaver!zephyr.ens.tek.com!tektronix!sequent!mntgfx!franka
From: franka@mentor.com (Frank A. Adrian)
Newsgroups: comp.arch
Subject: Re: New instructions for RISCs (was Re: Byte ordering)
Keywords: bitblt
Message-ID: <1990Feb10.154033.4271@mentor.com>
Date: 10 Feb 90 15:40:33 GMT
References: <7345@pdn.paradyne.com> <168@zds-ux.UUCP> <7366@pdn.paradyne.com>
Reply-To: franka@mntgfx.UUCP (Frank A. Adrian)
Organization: /etc/organization
Lines: 46

In article <7366@pdn.paradyne.com> alan@oz.paradyne.com (Alan Lovejoy) writes:
>BMERGE Rd, Rs, Rm; Rd = (Rd & ~Rm) | (Rs & Rm)
>
>Contents of Rd, Rs and Rm before instruction executes:
>Rm = 00000000000001111111111100000000
>Rs = 11000101011010000000110010110010 
>Rd = 00011010111101111100000111101000
>
>Contents of Rd, Rs and Rm after instruction executes:
>Rm = 00000000000001111111111100000000
>Rs = 11000101011010000000110010110010 
>Rd = 00011010111100000000110011101000

This is a good idea for an easily implementable instruction.

Instead of your proposed SPLICE instruction, I'd recommend a
BITEXT instruction which (using your notation, but where
[x:y] means bit indexing) looks like:

BITEXT Rd, Rs, Rdescr; Rd = Rs[Rdescr[11:6] : Rdescr[5:0]] >> Rdescr[5:0]

I believe the AMD 29K had a similar pair of instructions.
One problem with these types of instructions is that most
people are so used to poor perfomance with bitfields that
they code their own using the &, ~, ^, and | instructions
in C, rather than using the compiler's built in code gen-
eration.  This means that the instructions won't be used
much by existing software, so they won't increase bench-
mark performance very much, so they won't be included (1/2 :-).
Also to do the BITEXT (or your SPLICE) instruction ef-
ficiently, your barrel shifter has to become part of the
ALU datapath.  This may turn the whole thing into a net loss.

BTW, does anyone have an instruction format which uses the
source register specifiers as an immediate small constant
instead of a register specifier?  It seems to me, that as
most offsets and constants are small, the use of these
fields as direct operands, rather than having to burn a
register and an instruction for loading a small constant,
would be a win (even though it does start to look like
dat ol' debbil "addressing modes" :-).
-- 

Frank A. Adrian
Mentor Graphics, Inc.
franka@mntgfx.com