MISC design was discuss a lot in the f-cpu project. It was abandonned because it's impossible to keep backward compatibility. That's not a problem here.
From my point of view, the problem is how to manage the output of the unit. RISC like instruction permit to give an output register. So you could schedule instruction. In MISC, most read of the output will be at a fixed place. Mul.a <- Reg1 || Mul.b <- Reg2 Reg3 <- Mul.res || Mul.a <- Reg4 || Mul.b <- Reg 5 Reg6 <- Mul.res It's hard to do better. From a hardware point of view the "big switch" will be slow. But the killer are long latency instruction. Some could be predicted. Imagine how to schedule the read of a 32 cycles divide. Even worst : how do you manage the variable latency of a memory read ? For me, a shader instruction look like µinstruction : PC control, calcul and load&store in the same instruction world. Le mardi 18 Avril 2006 20:18, Timothy Baldridge a écrit : > >>MISC are a false good idea. Managing pipelined unit and latency are an > >>horrible task : if your FMAC is a pipelines unit, you have exactly one > >>time slot to read the output ! > > So? The compiler should be able to schedule this with no problem. I > could write the compiler to do this myself. If you can do 4 movs per > clock cycle, it should be no issue whatsoever. If you find my comments > in error, give me and example (and code to go with it) where the MISC > idea fails. > > > Okay, this has got me thinking now. What we need is a simple program > for testing how different processors function. What we need is a > simple program that can describe (in software) the characteristics of > the processor (latency, etc.) and run a simulation based on these > characteristics. Give me a week and I'll see what I can hash out... > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
