Hi Ali,
>
>
> Some of the instruction definitions change base on the register
> number. That is to say the bits that are in Ra/Rb/Rc control what code
> is emitted by the isa parser, so here the C++ constants are meaningless:
>
Ok, I understand your point here. However I have paired down the Alpha
decoder.isa, and it only contains about 10 instructions so far. So I
don't have any cases like that, currently, but thanks for the head up.
> Additionally, a noop is hard coded in isa_traits.hh:
> const ExtMachInst NoopMachInst = 0x2ffe0000;
A noop in our architecture is simply an empty opcode e.g. 0x00000000,
and is encoded as such. I have made the relevant change in isa_traits.hh.
>
> Finally, how are you ended up with the new binary that you're
> attempting to run? Are you manipulating an alpha binary? Unless you
> have some guarentee that everywhere r0 was used (when it wasn't a zero
> register) r31 will now be used it seems as though the registers and
> perhaps even the code that the compiler emits may be different.
The binary is in a standard elf format, compiled using an in-house LCC
port for our architecture. I have manipulated the elf loader to accept
our in house format, and it appears to be reading the correct
instructions from it (at least for the 10 or so instructions until the
execution paths diverge). I know that the code in the elf binary works
at least running on our in house simulator. In our architecture register
31 gets used to store values, and register 0 is hard-wired to 0, so it
is crucial that I can change the definitions of these registers,
otherwise the program will definitely make no "correct" forward progress.
Having followed Steve's suggestions I have debugged the the binaries
using gdb, and can indeed see that when ZeroReg is set to 31 (and
ReturnAddressReg is 0) then the code calls JsrAndLink, whereas when the
constants are switched the code calls Jsr, but I have extensively
searched to see where I may have missed a constant.
My simple decoder.isa file is attached below. I have omitted the
instructions that so far don't get touched.
Regards,
>%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%---
decode OPCODE default Unknown::unknown() {
0x01: decode INTFUNC {
format IntegerOperate {
0x00: add({{ Rc.sl = Ra.sl + Rb_or_imm.sl; }});
0x0b: and({{ Rc = Ra & Rb_or_imm; }});
}
}
format LoadAddress {
0x02: lda({{ Ra = Rb + disp; }});
0x03: ldah({{ Ra = Rb + (disp << 16); }});
}
format Store {
0x08: stb({{ Mem.ub = Ra<7:0>; }});
}
format Jump {
0x15: jsr(IsCall);
}
}
>%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%--->%---
>
> 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, 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 <m5-users@m5sim.org
>>> <mailto:m5-users@m5sim.org>>
>>>
>>> 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
>>>> 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
--
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
