Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!crackers!m2c!seqp4!jdarcy From: jdarcy@seqp4.ORG (Jeff d'Arcy) Newsgroups: comp.arch Subject: Re: Bitfield instructions--a good idea? Message-ID: <715@seqp4.UUCP> Date: 17 Apr 91 14:46:45 GMT References: <1991Apr17.174918.3458@waikato.ac.nz> Organization: Sequoia Systems, Marlboro MA Lines: 65 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. When I saw this in the manual, I wondered why one would ever use them. I eventually found a use; when emulating misaligned accesses I needed to do the effective address calculation manually, and for the scaled addressing mode this was most easily accomplished by extracting the instruction size into a register and then using that register as an argument to the next make-bitfield instruction. >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. Unlike your name, mine has a small "d". I'm sure you understand. Secondly, the 88K *does* have mask operations, lacking only the shifts which are merely subsets of the make/extract bitfield instructions. There is *no* shift operation which cannot be simulated in a single instruction this way. As for the variable-argument problem, the extra instructions to set up the operand would be present using shifts instead of bitfield ops. As it is, Motorola wisely allowed a width of 0 to mean "all bits to the left of the offset" (left = MSB), and the offset for the bitfield ops is in the *low* order five bits of the register operand. Consider the following: ; 88K notation is dst,src1,src2 - src1 is always a register ; extract (unsigned) bits 26-27 of r10 into r11 extu r11,r10,26<2> ; left shift r12 according to r11 mak r12,r12,r11 After the first instruction, r11 contains: 3 2 1 1098765432109876543210 98765 43210 +----------------------+-----+-----+ |0000000000000000000000|00000|000xx| +----------------------+-----+-----+ The field in the middle (bits 5-9) is the bitfield width; the field on the right (bits 0-4) is the bitfield offset. The second instruction therefore takes bits 0-31 (width of 0 gets translated to 32) of r12 and puts them in r12 starting at position (the extracted field from r10); excess bits on the left are of course discarded. The point of this detailed explation is thus: I don't know of any CPU that can do such a manipulation in *fewer* than two instructions, and I'd be rather surprised to find one. Hence, the "inconvenience" of Motorola's encoding is actually a win. (Any factual errors are the result of my not having at 88K manual handy since I don't work with the 88K any more) -- Jeff d'Arcy, Generic MTS, Sequoia Systems Inc. Yonder nor sorghum stenches shut ladle gulls stopper torque wet strainers