Re: [m5-users] Re: m5-users Digest, Vol 13, Issue 14

Ali Saidi Mon, 20 Aug 2007 08:33:13 -0700

Matt,

Some of the instruction definitions change base on the registernumber. That is to say the bits that are in Ra/Rb/Rc control whatcode is emitted by the isa parser, so here the C++ constants aremeaningless:


            // For AMASK, RA must be R31.
            0x61: decode RA {
                31: amask({{ Rc = Rb_or_imm & ~ULL(0x17); }});
            }

Additionally, a noop is hard coded in isa_traits.hh:
    const ExtMachInst NoopMachInst = 0x2ffe0000;

Finally, how are you ended up with the new binary that you'reattempting to run? Are you manipulating an alpha binary? Unless youhave some guarentee that everywhere r0 was used (when it wasn't azero register) r31 will now be used it seems as though the registersand perhaps even the code that the compiler emits may be different.


Ali

On Aug 20, 2007, at 6:13 AM, Matthew James Horsnell wrote:

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, anysuggestions

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 <m5-users@m5sim.org <mailto:m5-[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'tmean

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 iscompared 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 ajsr,

    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
m5-users@m5sim.org <mailto:m5-users@m5sim.org>
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users

End of m5-users Digest, Vol 13, Issue 14
****************************************


    _______________________________________________
    m5-users mailing list
    m5-users@m5sim.org <mailto:m5-users@m5sim.org>
    http://m5sim.org/cgi-bin/mailman/listinfo/m5-users



--
Matt Horsnell,
Advanced Processor Technologies Group,
University of Manchester.

_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users


_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users

Re: [m5-users] Re: m5-users Digest, Vol 13, Issue 14

Reply via email to