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? 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.) > I still think the modified version is better though, since it leaves one > slot open for a 16-bit immediate instruction and allows us to add a > large number of short immediate instructions if we wish by widening the > "shift-mode" (I call it QOPX in the new code, suggesting "extended" > operators). This is true. We should keep this for sure. > 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. -- Timothy Normand Miller http://www.cse.ohio-state.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)
