On Tue, Mar 26, 2013 at 10:08 AM, Mark Marshall <[email protected]>wrote:
> Hi. > > I think the FABS instruction has some spare bits (7), so we should encode > the bit to clear in those bits (don't assume bit 31). > This really makes the instruction a "bit-clear" instruction that can get > used for FABS. > > Adding a similar bit toggle instruction could be useful? (that would give > us fsign, but seems like it would be more useful than that). > I agree with you. With opcode=0 and the function field, we have "space" for lots of other useful and cheap instructions. So here are some bit setting/clearing functions you've inspired me to add: GPSW -- Get PSW into register SPSW -- Set PSW from register SBIT -- Set bit in GPR CBIT -- Clear bit in GPR NBIT -- Invert bit in GPR SBITI -- Same as above, but with immediate (stored where the source reg usually is) CBITI NBITI FS -- Set any combination of bits in PSW FC -- Clear any combination of bits in PSW So FABS is a CBIT instruction. FNEG could be implemented with FSUB, but this is a case where we could save energy by doing NBIT instead. > > The only difference between mulu and muls is that the flags will be set > differently - is this correct? > For SUB and ADD, it makes no difference, and since MIPS doesn't have a PSW, they decided to make an overflow exception. ADDU therefore masks the exception (and otherwise is no different!). For MUL and DIV, it makes a difference. Signed and unsigned versions have to be handled differently. Our implementation uses 33-bit inputs into the multiplier, so we just sign extend by 1 bit or not. > I'm not sure we need both? I also don't see any difference between mului > and mulsi? > Same issue. In this case, I decided (arbitrarily?) that the multiplier in the immediate field is unsigned, meaning that we just don't sign extend it. But MULSI sign extends the multiplicand, while MULUI does not. > > (The low n-bits of a n-bit by n-bit multiplication don't depend on whether > the numbers are signed or not). > You know, you might be right about that. Well, another opportunity for me to put a smack mark on my forehead. :) Also, one of the complaints I've gotten is that integer multiply doesn't yield a 64-bit result. So, time for another debate about the top portion of the product. We already have a special purpose register for the PSW. Why not add a HI register? We now need a way to get and set that into a GPR. We can combine that with GPSW/SPSW to make instructions that get and set special-purpose registers. Also, we have to decide what happens to the top portion if (a) the dest for the lower half is R0 and (b) the instruction is predicated false. I think for (b), we cancel both. For (a), if we write HI anyway, is that a counter-intuitive side-effect? > > If you wanted to use fewer opcodes all of SHLI, LSRI & ASRI could be given > the same opcode > and the type of shift could be encoded in some spare bits of the constant > (we only need 5-6 bits). > THAT's true. Right now, I look at the whole 32-bit shift value, and if the shift is too large, the register gets cleared (hmmm... maybe that should have been a cheap way to clear a register). But LOTS of architectures only pay attention to the lower 5 or 6 bits. So the question is: Do we support 5 or 6 bits? I realize any number > 31 will clear the register, but what if we want to future-proof for 64-bit? Why did 68000 look at 6 bits for this? > > I also wonder about how we load a 32-bit constant. Maybe the LI > instruction should allow loading a 21-bit number > and either right or left justifying it. Then to load a 32-bit number you > can use the LI instruction to load the high > bits and load the low bits with an ori. Well, MIPS had load-hi. But with the proposed changes, we can load a 31-bit immediate followed by an SBITI if necessary. No matter how you slice it, you get two instructions. On the other hand, if we toss LI, then we can salvage that one bit and use it for something else. But what? > > > > MM > > > On 24 March 2013 01:38, Timothy Normand Miller <[email protected]> wrote: > >> Here's another version. >> http://www.cs.binghamton.edu/~millerti/ins-formats3.pdf >> >> * This time, I've gotten rid of the WR bit and made R0 the bitbucket. >> * The top bit of the instruction is 1 for an LL instruction that loads a >> 31-bit immediate into R1. For all others, it's 0. >> * I added some more RX type instructions that may be convenient, like >> FABS, and NOT. >> * FNEG is really just FSUB(R0,x) >> * I'd like to group the RX type instructions together, so maybe they >> should be renumbered, and I realized that, well, there are unused bits, so >> I could group all RX types into a single function type and then have a >> function2 field for more of those. But I'll put that off until we decide >> that the RR function space is crowded. >> * I just realized that we can now ditch the MOV instruction altogether >> and replace it with OR(R0,X), but I didn't make that change yet. >> * I renamed the R1 instruction type to RX to avoid confusion with the >> register R1. >> >> -- >> Timothy Normand Miller, PhD >> Assistant Professor of Computer Science, Binghamton University >> http://www.cs.binghamton.edu/~millerti/ >> Open Graphics Project >> >> _______________________________________________ >> Open-graphics mailing list >> [email protected] >> http://lists.duskglow.com/mailman/listinfo/open-graphics >> List service provided by Duskglow Consulting, LLC (www.duskglow.com) >> > > -- Timothy Normand Miller, PhD Assistant Professor of Computer Science, Binghamton University http://www.cs.binghamton.edu/~millerti/ Open Graphics Project
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
