First of all I want to thank you for your response Avadh.
We well understand your tips in order to resolve the issue but I have
the following questions regarding the two options.
What can we do when the data_reload function won't be able to access the
data in one or more virtual memory addresses because for these virtual
addresses an exception is generated by the call of check_and_translate
and thus the function loadvirt cannot be called (in my understanding).
In such a case how could we update properly the data in caches?
Regarding the second option we will try to find the trick because as you
said it will be more efficient. However, I anticipate again that the
return of an exception after the check and translate will be an obstacle
for the call of loadvirt.
Do I miss something?
Thanks once again,
Sotiris
On 08/29/2014 09:07 PM, avadh patel wrote:
On Fri, Aug 29, 2014 at 4:39 AM, Sotiris Tselonis <[email protected]
<mailto:[email protected]>> wrote:
Furat thanks a lot for your response.
We are aware of the fact that in marss there are no data in caches
and thus we have implemented it. Especially, we update the data in
the arrays that we have implemented based on the requests that are
propagated through the memory hierarchy. Furthermore, when the
function loadvirt is called (within dcache_wakeup function), it
returns some data (lets define them data_from_loadvirt). According
to the level of hit in the cache hierarchy (if there is a hit), we
read from the corresponding cache the appropriate word of the
appropriate cache line (lets define them data_from_cache).
Usually the data_from_loadvirt are the same with the data_from_cache.
However, the data_from_loadvirt are different from the
data_from_cache up to 1% of all the calls of loadvirt function.
We are trying to find out the possible sources of the differences
between data_from_loadvirt and data_from_cache in order to resolve
the issue.
What is happening when the data in main memory are changed by a
complex instruction, that is handled by emulation mode? In our
understanding, the cache hierarchy is not updated correspondingly.
Would you suggest us any approach to address this issue?
There are couple of options you have here:
1) A simple but time consuming solution is to reload all the data in
cache after a complex instruction is executed, or when execution
control comes back to simulation engine. Remember that to handle IO
interrupts cycle accurate engine will give control to emulation engine
every once in a while. So add 'data_reload' call on these places and
you should be OK.
2) Trace all 'store' functions in QEMU that does a callback to your
function and update data in cache if present. This is more efficient
solution but the only trick is to correctly trace the stores.
- Avadh
On 08/29/2014 05:42 AM, Furat Afram wrote:
Hi
Marss does not store data in the caches. So I'm not sure where
the "data in cache" in your comparison came from.
-Furat
On Wed, Aug 27, 2014 at 9:16 AM, Sotiris Tselonis
<[email protected] <mailto:[email protected]>> wrote:
Dear all,
We are implementing an extension of the caches with data
arrays. However, we have observed cases that**our caches don'
t have
the data values that virtual memory seems to have.
Which are the possible sources of differences between data in
caches and that of main memory?
What is happening when the data in main memory are changed by
a complex instruction, that is handled by emulation mode?
In our understanding, the cache hierarchy is not updated
correspondingly.
Would you suggest us any approach to address this issue?
Thanks beforehand,
Sotiris
_______________________________________________
http://www.marss86.org
Marss86-Devel mailing list
[email protected]
<mailto:[email protected]>
https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
_______________________________________________
http://www.marss86.org
Marss86-Devel mailing list
[email protected]
<mailto:[email protected]>
https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
_______________________________________________
http://www.marss86.org
Marss86-Devel mailing list
[email protected]
https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
