Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!ogicse!intelhf!ichips!ichips!glew
From: glew@pdx007.intel.com (Andy Glew)
Newsgroups: comp.arch
Subject: Re: Bitfield instructions--a good idea?
Message-ID: <GLEW.91Apr18145129@pdx007.intel.com>
Date: 18 Apr 91 21:51:29 GMT
References: <1991Apr15.193425.3436@waikato.ac.nz> <712@seqp4.UUCP>
	<1991Apr17.174918.3458@waikato.ac.nz>
Sender: news@omews63.intel.com (News Account)
Organization: Intel Corp., Hillsboro, Oregon
Lines: 31
In-Reply-To: ldo@waikato.ac.nz's message of 17 Apr 91 05:49:18 GMT


    Someone else has kindly e-mailed me a description of the 88K bitfield
    instructions. They are truly remarkable animals, except for some reason
    the variable versions take *both* the offset and field width (as bitfields)
    from the same register.

    In other words, if you were dealing with a variable bitfield, you'd need
    another sequence of bitfield instructions (using fixed, immediate values for
    the width and offset) to set up the operands for the first one! I'd venture
    to suggest this would nullify any performance gain from trying to use bitfield
    instructions in the first place, except that Jeff D'Arcy also mentions that
    the 88K doesn't have any shift or mask operators, so you don't have the
    choice.

    Why did they design the 88K instructions to pack two operands into
    one register?

I hate to defend the 88K, now that I have moved from Motorola to
Intel, but setting up the dynamic operands in a register is acceptable
for one of the biggest uses of the bitfield operations - bitblt, where
the amount of the shift is known before the loop begins.  Setup once.


--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Parkway, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.