The change itself seems to be correct, but I'm not sure why it's necessary. Basically, what's going on with the code you're changing is that the instruction has a one byte immediate encoded as part of the instruction. The predecoder collects that one byte, and then sign extends it to 64 bits and stores it in the unsigned 64 bit immediate field of the ExtMachInst as it would any other immediate. In the decoder, we really want to recognize a special value of the original byte, but it's been sign extended so we need to compare the immediate that. What -should- happen, I think, is that the same value (0xff...ff80) would be in the immediate field no matter what the native width of the compilation is. The python should (again by my understanding) generate a comparison between that unsigned immediate constant and the uint64_t the same way all the time. Just a second...
(digs around a bit) I think what may be going on is that the integer constant stuck in the case statement is unadorned in the C++. In a 64 bit build, 0xffffffffffffff80 == 0xffffffffffffff80ULL, but in a 32 bit build, 0xffffffffffffff80 ~= 0xffffff80 != 0xffffffffffffff80ULL since warnings about int truncation must be turned off for the generated code. I have a fix for that in the x86 isa description someplace where it detects integers in python that will need ULL in C++ and sticks them on there when it generates code. (digs around some more) It's in arch/x86/isa/microops/limmop.isa. It doesn't detect if it needs a ULL, it detects if it's a number, and if it is it always puts it in ULL(). That's just to keep it from choking on variables, constants, etc. Since in this case it's an int for sure, it should suffice to stick a ULL on there. I don't know if there would be any performance implications with gcc doing 64 bit comparisons in the decoder all over for a 32 bit run, or if it would be smart enough to only do that when it needed to. Anyway, I think that sheds light on the problem. Please let me know if that presents some other, better solution that sticking in ULL. Gabe Nathan Binkert wrote: > The main thing in these two patches is allowing negative integer literals > in the isa parser so a negative IMMEDIATE can be decoded properly. > > I'm not positive that this is the correct fix, but given the comment, it > seems to be. Gabe, can you check it out? > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
