The relevant parts of the signatures of these two functions are: bits(T val, int first, int last)
and insertBits(T val, int first, int last, B bit_val) and in both cases, the number of bits being manipulated is calculated as first - last + 1, so the first value (both in name and in parameter ordering) should be the larger number. It looks like the code you copied above is wrong like you said, so please go ahead and put together a patch. Gabe On Thu, May 3, 2018 at 4:59 PM, Matt Sinclair <[email protected]> wrote: > Hi all, > > There appear to be several calls in the src/power/isa/decoder.isa file to > bits() and insertBits() (both in src/base/bitfield.hh) that have the first > and last fields backwards. Based on other calls to these functions in > decoder.isa, I believe first is supposed to be the MSb and last is supposed > to be the LSb. However the following calls seem to invert this assumption: > > decoder.isa: 583 > FPSCR = insertBits(FPSCR, k, k + 3, > bits(Fb_uq, k, k + 3)) > > decoder.isa: 161 > if(bits(Rs, n, n+7) == bits(Rb, n, n+7)) { > val = insertBits(val, n, n+7, 0xff); > } > > (for example, compared to the above calls line 464 has the opposite order > for first and last) > > Can someone please confirm if this is the case? Assuming I'm right, I can > push a patch. > > Thanks, > Matt > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
