Without looking into it too deeply what you're saying seems plausible.
The "best" place for this sort of initialization in SE mode is, in my
opinion, in the process initialization code. Conceptually it's sort of
like the OS constructing the process context. The situation sounds
similar to SPARC where 32 bit processes need to set a bit in a system
register that forces translation to truncate addresses.
Gabe
Korey Sewell wrote:
> Following up on this, it seems that Brad is correct about where the
> uninitialized values originate. Specifically, this code snippet in
> src/arch/alpha/tlb.cc is the culprit:
>
>> mode_type mode =
>>
>> (mode_type)DTB_CM_CM(tc->readMiscRegNoEffect(IPR_DTB_CM));
>>
>
> That uninitialized value eventually trickles down to these conditions:
> "if (!(entry->xwe & MODE2MASK(mode))) {"
> and
> "if (!(entry->xre & MODE2MASK(mode))) {"
>
> For SE mode, I'm wondering where/if the IPR registers are ever
> initialized? The indexing to the IPR registers get set in
> "initializeIprTable" but the actual registers themselves do not to my
> knowledge . Since SE is primarily just user_mode execution, I would
> guess typically the IPR registers dont matter for execution except for
> a case like this where TLB faults need to acquire a IPR value.
>
> If I set the IPR_DTB_CM register to an arbitrary value in the ISA
> constructor (arch/alpha/isa.cc), then the valgrind "uninitialized"
> error goes away. However, I'm not exactly sure what that value should
> be set to for a SE workload (i'm assuming in FS, the kernel sets that
> appropriately), and its not exactly the cleanest solution to hardcode
> that in the constructor even if I were sure of the right value.
>
> It's possible, that the uninitialized values causes the # of TLB
> faults in SE mode to change, allowing the actual simulation output to
> the stay the same but slightly changing the execution time and other
> "small" stats. That's just my theory though.
>
> Anyone have additional thoughts on this?
>
>
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
