Hi Steve, Thanks for the response. I appreciate that the *.isa files are outside of the scope of C++, but it appears that ZeroReg just gets pre-processed into the generated decoder.cc file and remains as ZeroReg. Presumably the value isn't actually resolved until the C++ code is compiled?
In the meantime, however, I replaced the constant 31 (which I had previously replaced with ZeroReg) with 0, in the *.isa files where a comparison was made, yet the two executed paths still differ. I'm beginning to run out of ideas for solving this problem, any suggestions would be appreciated. Regards, Steve Reinhardt wrote: > Here's my earlier message... > > ---------- Forwarded message ---------- > From: *Steve Reinhardt* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > Date: Aug 16, 2007 11:45 AM > Subject: Re: [m5-users] Re: m5-users Digest, Vol 13, Issue 14 > To: M5 users mailing list <[email protected] <mailto:[email protected]>> > > Thanks for the more specific explanation... that helped a lot. > > The decision about whether to update the link register or not is on > line 213 of src/arch/alpha/isa/branch.isa, and is indeed hard-coded to > check for RA equal to 31. It looks like the ISA decoder as a whole > only uses "31" and not a predefined constant for the zero register. > Note that this is outside of C++, so the ZeroReg constant doesn't mean > anything here. > > Steve > > > On 8/16/07, * [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>* > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > > > >"Steve Reinhardt" wrote > > > > I'm a little confused... shouldn't it behave differently when you > change > > the value of an important constant? :-) > > Sure I agree that it should behave differently, but shouldn't it > carry out > the same operations just on different registers as defined by the > constants? > > The key difference in the two traces is at global time 3000: > > When ZeroReg is 31, and ReturnAddressReg is 0 we see: > > 3000: system.cpu0: Fetch: PC:0x101b74 NPC:0x101b78 > 3000: global: Set register 31 = 0x0 > 3000: system.cpu0: Decode: Decoded jsr instruction: 0x54170000 > 3000: global: Read register 23 = 0x101a50 > 3000: global: Set register 0 = 0x101b78 > > Whereas when ZeroReg is 0, and ReturnAddressReg is 31 we see: > > 3000: system.cpu0: Fetch: PC:0x101b74 NPC:0x101b78 > 3000: global: Set register 0 = 0x0 > 3000: system.cpu0: Decode: Decoded jsr instruction: 0x54170000 > 3000: global: Read register 23 = 0x101a50 > > The final set register call is missing, and this is my confusion. > As far > as I can tell I've tracked down the obvious references to ZeroReg > which > were coded as 31. For example where the destination is compared to > 31 and > the op is replaced with a nop. > > But yet still I see this difference, I was just wondering if you > had any > ideas as to where it could occur. The operation occuring is a jsr, > which > is of the JUMP format (identical to alpha for now). > > I'll try the trace method you suggest. > > Thanks, > > Matt > > > > > > > > > I'm not too surprised that there are some hard-coded 31s in the > Alpha ISA > > definition; those should be converted to say ZeroReg if that's > what they > > are > > representing. > > > > I guess it's just not clear to me what "correct" behavior you're > expecting > > here. > > > > FYI, check out the "tracediff" tool in utils... it's invaluable > for seeing > > where two different executions diverge. I use it all the time with > > --trace-flags=3DAll or All,-Event. See the comments in the > script header > > f= > > or > > instructions, and let me know if you have any questions about it. > > > > Steve > > > > On 8/15/07, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > >> > >> I am progressing with my ISA implementation. As mentioned before > I am > >> porting the Alpha ISA to use our in house ISA. > >> > >> Interestingly, today when I tried to change the ZeroReg > definition (reg > >> 31 > >> in alpha) to reg 0, I get different output from a trace run of > the first > >> few instructions of my program (a binary compiled to our ISA, have > >> manipulated the elf libraries to accept it in m5). > >> > >> Can anyone tell me why there is a reliance on ZeroReg (and > >> ReturnAddressReg) being redefined? A quick search of the alpha code > >> (which > >> my port is based on) reveals that a lot of hard-coded constants are > >> still > >> left in the code (=3D=3D 31, !=3D 31 etc), I have tried changing > these > >> to= > > (=3D=3D > >> ZeroReg, !=3D ZeroReg) in my port, but I still get incorrect > output when > >> defining ZeroReg as 0. > >> > >> I've not yet had a good luck inside the ISA specific parts of > the CPU > >> code, are there any hard-coded constants there? > >> > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > http://m5sim.org/pipermail/m5-users/attachments/20070815/71272d50/atta= > > chment.html > > > > ------------------------------ > > > > _______________________________________________ > > m5-users mailing list > > [email protected] <mailto:[email protected]> > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > End of m5-users Digest, Vol 13, Issue 14 > > **************************************** > > > > _______________________________________________ > m5-users mailing list > [email protected] <mailto:[email protected]> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > -- Matt Horsnell, Advanced Processor Technologies Group, University of Manchester. _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
