On Sun, Apr 21, 2013 at 2:58 AM, <[email protected]> wrote: > Le 2013-04-21 03:57, Timothy Normand Miller a écrit : > >> BTW, Ive changed some of the opcodes: >> http://www.cs.binghamton.edu/~**millerti/ins-formats4.pdf<http://www.cs.binghamton.edu/~millerti/ins-formats4.pdf>[3] >> > > "MUL instructions write top 32 bits to" > > A long time ago I played with the idea of > using destr+1 as implicit destination for > 2W instructions... But in your case, > you don't seem to like the idea of a 2R2W > register bank.
Yeah, if it happened a LOT, then it would be worth it. But for only a handful of instructions, it's a waste of logic. Similar could be said about the HI data path and the extra register. But adding another port to an SRAM is REALLY expensive. > Fine but now you have a > heterogenous register file :-/ > Yes. I have to accept that there are a few special-purpose registers we'll want to save and restore, like PSW. I had left out the HI part before because I figured getting the top half would be rare. It's probably a bad decision to add a whole extra 32-bit data path for a rare operation. The energy to compute an extra multiply now and then would probably cost less over-all than an otherwise unused extra datapath. I think I'll use your idea. :) > > Lately i've done differently : > mul and mulhi instructions, > which select which part to put > on the result bus. > Consumption wise, if you emit/decode > a consecutive pair of mul+mulhi, > the operands and results remain the same > (only the very last part is changed) so > no big energy draw. But that is valid > for an in-order CPU, not a barrell CPU > where data are multiplexed from different > threads... > > What do you think ? Yeah. Ok, so what I need is MUL (signed and unsigned are the same for the lower half) and then two instructions for getting the upper halves (a total recompute, but whatever), one signed, the other unsigned. What should I call them? MULU and MULS don't indicate "hi", and MULUHI and MULSHI look ugly. :) > > > yg > > -- 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)
