At the end of svc instruction, R0 is being updated. On what case is R0
changed?
Thanks
V Vanchinathan
On Thu, Aug 28, 2014 at 2:20 PM, Vanchinathan Venkataramani <
dcsv...@nus.edu.sg> wrote:
> At the end of svc instruction, R0 is being updated. On what case is R0
> changed?
>
> Thanks
> V Vanch
Hi,
I have been running with the debug flag option for DRAMPower for memory
power consumption however I noticed that there are no writes in any of the
traces generated no matter the CPU type, seems write commands does not get
registered from mem_cntrls.
Best Regards
Hussain
__
Hi Mitch,
After I applied two patches and IsQuiesce modification, O3 CPU keeps
in the same track as atomic CPU longer than before. But apic_timer_interrupt
function comes out again in O3 CPU. It used to come out after about 500,000
instructions, now it comes out after about 990,000 instructions.
Hi All,
MOESI CMP directory in Ruby models the L2 controller with a L2 cache and a
Local Directory(modelled as PerfectCacheMemory).
MOESI_CMP_directory being a Non-Exclusive Protocol, stores the meta data
about the lines not present in L2 but present in one of the L1s, in the
Local Directory.
Thi
Yep, that should do it.
On Wed, Aug 27, 2014 at 2:57 PM, Zi Yan wrote:
> Thanks.
>
> I will apply 1, and 2 patches.
>
> For 3, I need to change the file src/arch/x86/isa/microops/specop.isa:66
> from
> setFlags | (ULL(1) << StaticInst::IsNonSpeculative),
> to
> setFlags | (ULL(1) << StaticInst:
Thanks.
I will apply 1, and 2 patches.
For 3, I need to change the file src/arch/x86/isa/microops/specop.isa:66
from
setFlags | (ULL(1) << StaticInst::IsNonSpeculative),
to
setFlags | (ULL(1) << StaticInst::IsNonSpeculative) | (ULL(1) <<
StaticInst::IsQuiesce),
Am I doing the right thing to ta
There are probably three main patches that could help. The fact you
mention the timer interrupt makes me think Andreas is right and these might
solve your issue.
1. http://reviews.gem5.org/r/2363/ - o3 is supposed to stop fetching
instructions immediately once a quiesce instruction is encountere
OK. Could you please tell me which patches are there? In the
review board there are quite a lot of new patches waiting
for review.
I can apply those patches myself and do a quick test.
Thanks.
--
Best Regards
Yan Zi
On 27 Aug 2014, at 13:56, Andreas Hansson wrote:
> Hi Yan,
>
> I would suspect
Hi Yan,
I would suspect this is due to a bug in the X86 O3 CPU. There have been
quite a few fixes posted on the review board for similar issues. I hope to
have these committed in the next week or so.
Andreas
On 27/08/2014 18:02, "Zi Yan via gem5-users" wrote:
>Hi all,
>
>I am running kmeans v
Hi all,
I am running kmeans via hadoop in gem5 X86 FS mode. I am using
linux kernel 3.2.60 with configuration file linux-2.6.28.4 from
gem5.org.
I take a checkpoint before a map task and put a "m5 exit" after the map task.
I am using *X86kvmCPU* to take checkpoints.
When I restore from the sam
I just I remembered the other real problem with implementing fully
pipelined fetch. We'd have to re-do how the branch predictors are
currently done.
Currently the gem5 branch predictors "cheat" in that they have full access
to the decoded instruction (unconditional, indirect, RAS push/pop, etc).
Hi all
I would like to know how svc (trap) instruction is implemented in gem5.
In particular I want to know on what condition the register values are
changed when svc syscall is present.
Thanks a lot!
___
gem5-users mailing list
gem5-users@gem5.org
htt
Hi Andreas,
Thanks for the clear response.
I will try ARM at first. And after that I may try to fix the RMW.
Chao Zhang
Peking University
On Aug 27, 2014, at 3:48 PM, Andreas Hansson wrote:
> Hi Chao,
>
> Unfortunately the classic memory system does not support X86 atomic RMW
> operation
Hi Prathap,
You can easily create a subclass of the BaseCache and give it suitable
parameters for an L3. This should be fairly straight forward and also easy to
instantiate in the Python scripts (e.g. fs.py)
Andreas
From: Prathap Kolakkampadath via gem5-users
mailto:gem5-users@gem5.org>>
Repl
Hi Chao,
Unfortunately the classic memory system does not support X86 atomic RMW
operations. This is why it works in atomic and not in timing.
You options are:
1) implement a fix and do everyone a big favour (I vote for this one)
2) take the hit in simulation speed and switch to Ruby and stick t
15 matches
Mail list logo