If registers are precious, why not add more? .. what is the relative cost (in terms of latency, silicon area, and energy) to double the register set size?
So what if we have 8 'bitbucket/constant' registers of these most used constants, and then instead of hardcoding the constants, make them be something the application can load. As for the dependency issue, I think the point of the bitbucket register(s) was that they have none, and we throw away all writes going to those registers. On Mon, Mar 18, 2013 at 09:53:09AM +0100, Nicolas Boulay wrote: > Registers are a very precious ressources. Memory are more and more slower > than the CPU (it's even worse from the latency point of view). So having a > register code for /dev/null is a coslty solution, if we have constraint on > the instruction size. A cpu with large code have more pressure to reduce > the code size, than a gpu where the code is smaller. > > MSP430 use 16 and 32 bits instruction size, 32 bits instruction use the > second 16 part as immediat, it's quite clean. > > One of the new cpu have a specific encoding for constant. It's like having > 3 bits that code 8 values includes -1, 0, 1, 2, 4, 8, 16, the most used > constant to avoid to use larger code. > > - Large instruction world is coslty only on large code > - dependencies between register is always a plague for performance on > pipeline > - Register and register adress space is one of the most precisous > ressources of a cpu > - immediat could be coded as enum or constant name for the most used value > > Nicolas > > 2013/3/17 Timothy Normand Miller <[email protected]> > > > > > > > > > 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) > > > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) -- -------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' [email protected] Somone asked my why I work on this free (http://www.fsf.org/philosophy/) software & hardware (http://q3u.be) stuff and not get a real job. Charles Shultz had the best answer: "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shultz _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
