On Sun, Mar 17, 2013 at 4:31 PM, <[email protected]> wrote: > Le 2013-03-17 21:20, Timothy Normand Miller a écrit : > <snip> > > I'm looking here at the bit compactness, because > less bits means less toggles and less power draw. > > Using a bit for each instruction to throw the register away : 1 > bit/instruction > > Using R0 : if you have, say, 64 registers, R0 will amount to 0,09 > bits/address, > or if you use 3 addresses : 0,28 bits/instruction. > Drawback : you have to add 3 6-input OR gates to decode the R0 condition, > or create a custom register set where R0 is "hardwired". > However, all array generators need a regular, homogenous addressing space. > FPGAs, ASICs etc. prefer and want memories where all the cells are > identical. >
The logic for this isn't a big deal. We can MUX in a zero for R0 source, and there are a few good ways to cancel writeback for R0 destination. (We could also initialize R0 to zero if it's a source else otherwise just not write to it, but my reliability intuition tells me not to do that.) > > > From a compactness point of view, it seems that an explicit opcode is > needed, > as "throwing away" the result is limited to only a handful of cases. > For the most part, yes. x86 has CMP (special case of SUB) and TEST (special case of AND), and that latter one is unusual. > > That's only an opinion and the best solution depends on each case. > So, the next question is, what would one of the bit-saving solutions buy us? I think for the most part, it would allow us to extend immediates to 17 bits, and that's about it. Speaking of immediates, I was thinking about our earlier discussion of MUX vs. MOV. Instead of MUXI, we'd get MOVI (or LDI, same thing), where all we need is an opcode and a dest reg, and we could have a 23-bit immediate. (For LDI, wr would be inferred to be 1, wf would be zero, and the predicate would of course be true. There would be another instruction format, LI.) I'll probably make that change soon. > > YG > ______________________________**_________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/**mailman/listinfo/open-graphics<http://lists.duskglow.com/mailman/listinfo/open-graphics> > List service provided by Duskglow Consulting, LLC (www.duskglow.com) -- 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)
