baum@apple.com (Allen Baum) (04/19/91)
In article <1991Apr17.164832.23138@dg-rtp.dg.com>, hamilton@siberia.rtp.dg.com (Eric Hamilton) writes: > > 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. As someone pointed out, this is because they couldn't use any more register ports, and they wanted both length and position to be variable, AND they didn't want to add a special register (the 88k designers were very allergic to 'special' registers, for reasons they feel are very good). > 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) > HP statistics indicated that AND and OR immediates were generally contiguous fields of bits, and hence could be handled by a more general (& more concise) set/clr field mechanism, which is done with the deposit immediate form.