On Tue, Oct 27, 2009 at 5:35 PM, Petter Urkedal <[email protected]> wrote: > On 2009-10-27, Nicolas Boulay wrote: >> 2009/10/26 Timothy Normand Miller <[email protected]>: >> > Also, no flags. I'm very much a fan of the MIPS approach because it >> > doesn't create any of these extra inter-instruction dependencies >> > through a narrow straw. >> >> I don't know the MIPS approach but we could also use the itanium >> approch that use "bit" register. Then you can use it for branch as >> boolean register. so there is no hidden dependancies (like in ARM with >> branch that depend on the alu flags) > > I read on Wikipedia that Itanium has 64 predicate registers. I like > this, as it saves register space. But I'm not sure if we'll manage to > use the extra bits of the BRAMs this way, since we'd need a way to write > to the upper 4 bits without affecting the lower 32 bits. > > Alternatively we can use two or four dedicated entries of the register > file for these predicate registers. That will introduce extra decoding > logic, which may introduce timing issues in connection with the BRAM > fetches.
Predicates can save some cycles to avoid branches, but mostly they avoid stalls. The only stall we have is from a memory read, which is unavoidable. So we don't benefit much from predicates. If we have 256 local regs, and we have three operands, then 24 bits of our instruction word are typically used up for register numbers. That leaves 8 bits for the opcode, which I just don't think has room for predication. In theory, we could extend the instructions to 36 bits. But that would complicate how code is stored in graphics memory. -- 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)
