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)
