Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!appserv!sun!amdcad!dgcad!dg-rtp!siberia!hamilton From: hamilton@siberia.rtp.dg.com (Eric Hamilton) Newsgroups: comp.arch Subject: Re: Bitfield instructions--a good idea? Message-ID: <1991Apr17.164832.23138@dg-rtp.dg.com> Date: 17 Apr 91 16:48:32 GMT References: <1991Apr15.193425.3436@waikato.ac.nz> <712@seqp4.UUCP> <1991Apr17.174918.3458@waikato.ac.nz> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: hamilton@siberia.rtp.dg.com (Eric Hamilton) Organization: Data General Corporation, Research Triangle Park, NC Lines: 63 In article <1991Apr17.174918.3458@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: |> |> 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. The 88000 has shift operations. It gives you all flavors (left, right, arithmetic, logical, constant or variable shift count) in one clock. They're special cases of the bitfield operations, so they may not be recognized as shifts, but they are. The 88000 also has mask operators (rd,rs1,rs2 are registers, imm16 a 16-bit literal): and rd,rs1,rs2 rd = rs1 & rs2; and.c rd,rs1,rs2 rd = rs1 & ~rs2 and rd,rs1,imm16 rd = rs1 & (0xffff0000 | imm16) and.u rd,rs1,imm16 rd = rs1 & (0x0000ffff | (imm16 << 16)) mask rd,rs1,imm16 rd = rs1 & imm16 mask.u rd,rs1,imm16 rd = rs1 & (imm16 << 16) as well as the bit-field operations. Packing the operands of the variable bit-field operations into one register doesn't really impose much performance penalty (all instructions are single-cycle): Any shift (constant or variable shift count): 1 instruction. Any constant width and offset bitfield operation: 1 instruction. Any variable width, zero offset operation: 2 instructions. Any variable width, non-zero offset operation: 3 instructions. Any variable width, variable offset operation: 3 instructions. These are not the penalties - they're the total instructions to perform the operation. They're pretty good, especially if you consider the dynamic frequency of the variable width and offset operations. I think you'll be hard-pressed to better with shift-and-mask sequences. |> |> Why did they design the 88K instructions to pack two operands into |> one register? |> With the operands packed, the bit field operations are already three-register instructions: source, destination, and width/offset specifier. For a single-cycle operation, that's about all that's reasonable - five more bits in the instruction to specify another register, and another read port in the register file, just so we can do variable-width/length operations in one or two fewer cycles? That can't be right. -- ---------------------------------------------------------------------- Eric Hamilton +1 919 248 6172 Data General Corporation hamilton@dg-rtp.rtp.dg.com 62 Alexander Drive ...!mcnc!rti!xyzzy!hamilton Research Triangle Park, NC 27709, USA