[FeS2-devel] bug in pyrite/DynamicInst.cpp

[junli gu]

Dear Naveen,

   Welcome back to town!
   This is Junli Gu. I  and Byn Choi are friends. (I think Byn has mentioned
to you about having me to your picnic or party thing. I would like to meet
you and beautiful girlfriend :)   )   I am not writing about the picnic,
though. I am using FeS2 and simics for multi-core research. I wrote you
before about the bug in pyrite. I am writing to get your confirmation about
the cache hierarchy in ruby.

 In my experiment I set up 8 cores CMP with L2 shared cache. I noticed that
the default coherence ptotocal is MOSEI_directory. I am confused that is the
L2 cache shared or private? It seems to be private.

  If it's private, I may not use it. Is there a way to use a L2 shared cache
ruby prototal to work with FeS2? I know GEMS has MSI_MOSI_CMP_directory
protocal, which is pretty new. I tried to compile FeS2 using it, however
failed because of format.  Is there a way to update the coherece protocals
of FeS2 using?

  Thank you very much!

2010/2/22 junli gu <junligu at illinois.edu>

> Sorry I forgot to attach the file in last email.
>
> 2010/2/22 junli gu <junligu at illinois.edu>
>
> Dear Naveen,
>>
>> Sorry for the late reply.
>>
>> I thought about sending you the testcase so that you can just run the
>> test. But then i found out the disk image and .conf files are too big to
>> send though emails. I am sending the Dyanmic.cpp file to you, which i modify
>> the addressGenerate() function :
>>  take off :
>>
>> assert(addr >= (W64)m_processor)
>> and print out the following info:
>> if (addr < (W64)m_processor) {
>>       printf("BROKEN INST uop: %d  phys_addr(vir_addr) : %x(%x) num_bytes:
>> %d\n", m_q_ptr, (unsigned)phys_addr, (unsigned)addr, num_bytes);
>>
>> You can just recompile the project with file and run some simple
>> helloworld program to test.  I am running MPI programs on the simulator. But
>> I think the case happens in to regular programs.
>>
>> Let me know if it works or not.
>>
>>
>> On Wed, Feb 17, 2010 at 7:17 PM, Naveen Neelakantam <
>> neelakan at illinois.edu> wrote:
>>
>>> Hi Junli,
>>>
>>> Thank you very much for the information.  Do you also happen to have a
>>> small testcase I could try out to trigger the bug?  If so, I am happy to
>>> take a look (but not until this weekend, unfortunately).
>>>
>>> Actually, come to think of it, x87 is not really supported by FeS2.  If
>>> you are executing code with a lot of x87 in it then you will likely see a
>>> very high rate of simulation errors.  Is it possible for you to use SSE/SSE2
>>> instead?
>>>
>>> BTW, I am still officially not supporting FeS2.  ;-)
>>>
>>> Naveen
>>>
>>>
>>> ---- Original message ----
>>> >Date: Wed, 17 Feb 2010 17:53:46 -0600
>>> >From: junli gu <junligu at illinois.edu>
>>> >Subject: [FeS2-devel] bug in pyrite/DynamicInst.cpp
>>> >To: FeS2 Development <fes2-devel at cs.uiuc.edu>
>>> >
>>> >   Dear Naveen,
>>> >
>>> >   I noticed that you made a post about not
>>> >   understanding when one of the
>>> >   assertions in pyrite/DynamicInst.cpp might fail.
>>> >
>>> >   The assertion in question is in
>>> >   DynamicInst::addressGenerate and says...
>>> >
>>> >   assert(addr >= (W64)m_processor);
>>> >
>>> >   The assumption here is that any internal load/store
>>> >   (mapped for control
>>> >   registers, etc.) must sit within the Context class
>>> >   from which Processor
>>> >   derives, and therefore the address must be larger
>>> >   than that of the
>>> >   pointer to the processor instance associated with
>>> >   the dynamic instruction.
>>> >
>>> >   That assumption is incorrect when, for example, one
>>> >   of the x87
>>> >   instructions executes.  If you look in
>>> >   decode/decode-x87.cpp, you'll
>>> >   see that some internal instructions reference the
>>> >   static table
>>> >   translate_cmpccf_to_x87.  Obviously, since static
>>> >   data is generally
>>> >   going to come earlier in the address space than
>>> >   dynamically allocated
>>> >   data like Contexts, the assertion fails for these
>>> >   instructions.
>>> >
>>> >   I hope this will help.
>>> >
>>> >   --
>>> >   ************************************************
>>> >   Junli Gu--¹È¿¡Àö
>>> >   Coordinate Science Lab
>>> >   University of Illinois at Urbana-Champaign
>>> >   ************************************************
>>> >________________
>>> >_______________________________________________
>>> >FeS2-devel mailing list
>>> >FeS2-devel at cs.uiuc.edu
>>> >http://lists.cs.uiuc.edu/mailman/listinfo/fes2-devel
>>>
>>> _______________________________________________
>>> FeS2-devel mailing list
>>> FeS2-devel at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/fes2-devel
>>>
>>
>>
>>
>> --
>> ************************************************
>> Junli Gu--¹È¿¡Àö
>> Coordinate Science Lab
>> University of Illinois at Urbana-Champaign
>> ************************************************
>>
>
>
>
> --
> ************************************************
> Junli Gu--¹È¿¡Àö
> Coordinate Science Lab
> University of Illinois at Urbana-Champaign
> ************************************************
>



-- 
************************************************
Junli Gu--¹È¿¡Àö
Coordinated Science Lab
University of Illinois at Urbana-Champaign
************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/fes2-devel/attachments/20100506/3b7a22e9/attachment.html