On 2008-01-09, Timothy Normand Miller wrote: > On 1/9/08, Petter Urkedal <[EMAIL PROTECTED]> wrote: > > > > The claim that we save an instruction for multiply is a mistake on my > > part. What I didn't consider is that the code depends on shifting out > > the bits and testing when the operand becomes zero to determine the stop > > condition. That does not work with rot. > > Oops. You're right. <sigh> With a CPU with separate condition > codes, you can use a regular shift and test against carry, but not > here. > > What else could we do to optimize multiply?
Apart from jump-if-odd? Maybe we'll just leave it until we start coding and see what we need. > Are there any other uses for ROT? (If not, it's low-hanging fruit for > removal should we have trouble meeting timing or area constraints.) A nice feature about it is that it's reversible, so that we can process the bits (or bytes) without destroying the original. But, I don't know if it's going to be that useful. We should keep the possible removal of rot in mind if we start writing code before optimising. > > You mean in the RTL? I think it's all there in "`define"s, but maybe > > you're thinking of more like a table. I could add more low-level info > > into oga1hq-manual.tex when things are stable, enough that someone could > > write an alternate assembler if they wish. But, if written in C, it's > > easiest to just use oga1hq.h and oga1hq.c (the code generator > > "mini-library"). > > It just took me some extra time to figure it out. When I realized > (and remembered) that direction is encoded in the sign, that helped. > Then I came to understand how you cleverly encoded right/left/rotate > by computing them all and ORing the pieces together, and it all made > sense. Yes, the shifter code is a bit terse. I'll add some comments to it. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
