Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!spool.mu.edu!munnari.oz.au!bruce!dec19!zik
From: zik@dec19.cs.monash.edu.au (Michael Saleeba)
Newsgroups: comp.arch
Subject: Re: Bitfield instructions--a good idea?
Message-ID: <zik.671779924@dec19>
Date: 16 Apr 91 05:32:04 GMT
References: <1991Apr15.193425.3436@waikato.ac.nz>
Sender: news@bruce.cs.monash.OZ.AU
Lines: 24

In <1991Apr15.193425.3436@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:

>What do RISC designers think of bitfield instructions? (A la
>the VAX and 680x0 [x >= 2] processors: extract so many bits at
>a certain offset, insert so many bits at a certain offset, etc.)

I rather like the Texas Instruments graphics processors' attitude to this
problem. All instructions are addressed by bit, irrespective of the maximum
physical word size, and most instructions (as far as I remember) allow a
nice range of bitfield lengths for their operands. Surely this is a neater
way to design a system than to rely on combinations of arbitrary byte and
word boundaries.

It could be argued that this would lead to a conflict with the basic goals of
RISC design and general inefficiency. I suppose the best comment here is that
the TMS34010 and TMS34020 are quite RISCy, and are also pretty damn fast;
mainly through exploiting RISC design goals.

 ______      _
|___  /  _  | | __	"I don't want the world - I just want your half."
   / /  |_| | |/ /
  / /    _  |   / 		Name:		Michael Saleeba
 / /__  | | |   \ 		At:		Monash University
/_____| |_| |_|\_\		E-mail:		zik@bruce.oz.au