[m5-dev] Ruby Store/Coaslescing Buffer Implementation for TimingSimpleCPU

Hello, I am interested in implementing a storebuffer (coalescing buffer) for Ruby's Memory Model in M5/GEM5 for use in my current research. I wish to be able to coalesce speculative stores + non-speculative stores to the same cache line and then flush them to the cache during certain acquire/rele

Re: [m5-dev] Early Branch Resolution in O3

On 03/27/11 20:14, Ali Saidi wrote: > On Mar 27, 2011, at 3:19 PM, Gabe Black wrote: > >> On 03/27/11 13:13, Ali Saidi wrote: >>> On Mar 26, 2011, at 4:48 PM, Korey Sewell wrote: >>> I'm bumping the below e-mail from the users lists to dev. I believe it is a legit problem with decode not

Re: [m5-dev] Early Branch Resolution in O3

On Mar 27, 2011, at 3:19 PM, Gabe Black wrote: > On 03/27/11 13:13, Ali Saidi wrote: >> On Mar 26, 2011, at 4:48 PM, Korey Sewell wrote: >> >>> I'm bumping the below e-mail from the users lists to dev. I believe it >>> is a legit problem with decode not actually passing back the correct >>> valu

Re: [m5-dev] Checkpointing

On Sun, Mar 27, 2011 at 1:27 PM, nathan binkert wrote: >> Is there any reason to have a serialize function in the timing and o3 cpus? >> Creating a checkpoint from them will be broken since if you're using cache >> the dirty data won't be saved? Shouldn't we change their implementation to >> fa

Re: [m5-dev] Checkpointing

> Is there any reason to have a serialize function in the timing and o3 cpus? > Creating a checkpoint from them will be broken since if you're using cache > the dirty data won't be saved? Shouldn't we change their implementation to > fatal()? Is the implementation of the CPUs correct? Arguably

Re: [m5-dev] Early Branch Resolution in O3

On 03/27/11 13:13, Ali Saidi wrote: > On Mar 26, 2011, at 4:48 PM, Korey Sewell wrote: > >> I'm bumping the below e-mail from the users lists to dev. I believe it >> is a legit problem with decode not actually passing back the correct >> value for taken/not taken to the branch predictor when it det

Re: [m5-dev] Review Request: config: revamp x86 config to avoid appending to SimObjectVectors

> On 2011-03-26 12:31:49, Gabe Black wrote: > > src/arch/x86/bios/E820.py, line 53 > > > > > > I think at least most of these lists should be allowed to be empty > > regardless of if they're being appended to. > > Steve Rei

Re: [m5-dev] Cron /z/m5/regression/do-regression --scratch all

Traceback (most recent call last): File "", line 1, in File "/z/m5/regression/zizzer/m5/src/python/m5/main.py", line 348, in main exec filecode in scope File "tests/run.py", line 70, in execfile(joinpath(tests_root, 'configs', test_filename + '.py')) File "tests/configs/simple-tim

[m5-dev] Cron /z/m5/regression/do-regression --scratch all

M5 exited with non-zero status* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby FAILED! * build/AL

Re: [m5-dev] Early Branch Resolution in O3

On Mar 26, 2011, at 4:48 PM, Korey Sewell wrote: > I'm bumping the below e-mail from the users lists to dev. I believe it > is a legit problem with decode not actually passing back the correct > value for taken/not taken to the branch predictor when it detects a > pc-relative, unconditional contr

[m5-dev] Checkpointing

Is there any reason to have a serialize function in the timing and o3 cpus? Creating a checkpoint from them will be broken since if you're using cache the dirty data won't be saved? Shouldn't we change their implementation to fatal()? Thanks, Ali ___