> What do you mean by "given a certain prefix"? X86's encoding is fairly > amorphous, and it's not always possible to tell early on how big an > instruction will be. It's possible in general of course, so it depends > on what you actually mean there. Would chasing through linked lists like > that slow things down a lot with memory dependencies, caching, etc.? Let me be precise. Given a valid instruction array inst1 with length i, is it ever possible for there to be a valid instruction array inst2 of length j where j != i and inst1[k] == inst2[k] where 1 <= k <= min(i,j).
A concrete example. Is it ever possible for an instruction that's 8 bytes long to have the same 8 bytes as the first 8 bytes of an instruction whose length is greater than 8. As for the pointers (it's not a list, it's a tree). The maximum depth of the tree is equal to the maximum length of and instruction in bytes and the average depth is the average instruction length. > We > would have to find some way of keeping the bytes around at least to > reprocess with the predecoder on a miss, and it might be easiest to do > that byte by byte since the alignment is arbitrary. The way I hash the > ExtMachInst right now is just to pack all the fields together into same > lengthed chunks, xor those, and then hash the result, and that may just > not be a very good hash function. By putting things into a tree we might > avoid the entire issue of wonky roll-your-own hash functions. All in all > I'm not sure the tree idea would work, but it's definitely at least good > to consider. What don't you think would work about it? One benefit of it is that you don't need to know how long an instruction is. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
