[m5-dev] changeset in m5: X86: Create a common flag with a name to indica...

changeset 36131e4dfb6e in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=36131e4dfb6e description: X86: Create a common flag with a name to indicate scalar media instructions. diffstat: 16 files changed, 134 insertions(+), 115 deletions(-) src/arch/x86/insts/micromediaop

Re: [m5-dev] changeset in m5: X86: Create a common flag with a name to indica...

These changes to the media uops work towards cleaning up ext but don't cover everything yet. This was to prevent what I had working from going stale again. Gabe Gabe Black wrote: > changeset 335f8b406bb9 in /z/repo/m5 > details: http://repo.m5sim.org/m5?cmd=changeset;node=3

Re: [m5-dev] changeset in m5: X86: Record the memory mode when building an X8...

86_FS that uses -t. Gabe Gabe Black wrote: > changeset e649cb8af113 in /z/repo/m5 > details: http://repo.m5sim.org/m5?cmd=changeset;node=e649cb8af113 > description: > X86: Record the memory mode when building an X86 system. > > diffstat: > > 1 file changed, 2 insertio

[m5-dev] changeset in m5: MIPS: Add missing syscall slots.

changeset aa9e72a7d8d3 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=aa9e72a7d8d3 description: MIPS: Add missing syscall slots. These are all after the existing ones, suggesting they were added after the original list was created. diffstat: 1 file cha

Re: [m5-dev] MIPS double-precision floating point

I notice that you comment out some function calls in this patch, and that's probably not the right thing to do. You wouldn't be the first, but generally it's better to either fix the problem by fixing the function, to get rid of the broken implementation entirely (probably too drastic), add a warni

Re: [m5-dev] MIPS double-precision floating point

This looks right to me and good catch. Does this look right to you, Korey? We should be able to get this in immediately by leaving off the change to the filterDoubles function for now. Gabe Matt wrote: > I stumbled across another MIPS floating-point problem. This one has > to do with conversion

Re: [m5-dev] MIPS double-precision floating point

ked "64-bit FPU Only" in the > MIPS reference manual should throw some kind of warning or error if > they are ever executed in M5 (if it cannot be configured to support > 64-bit wide FP registers) instead of just silently doing something > unpredictable. > > On Tue, Dec 29, 200

Re: [m5-dev] MIPS double-precision floating point

Korey Sewell wrote: > The first thing I would say is that implementing this could get > interesting but definitely is doable within the current framework. > > #1 is that how do you detect a 64-bit FPU despite 32-bit INT > registers. I assume that some system register is set (cop0) so what > you ne

[m5-dev] changeset in m5: MIPS: Extract CPU pointer from the thread conte...

changeset 45879b0e3240 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=45879b0e3240 description: MIPS: Extract CPU pointer from the thread context in scheduleCP0 setMiscReg. The MIPS ISA object expects to be constructed with a CPU pointer it uses to loo

[m5-dev] changeset in m5: MIPS: Create an artificial control register to ...

changeset 14fbdb0f9585 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=14fbdb0f9585 description: MIPS: Create an artificial control register to hold the thread pointer. In Linux, the set_thread_area system call stores the address of the thread local stor

[m5-dev] changeset in m5: MIPS: Implement the set_thread_area system call.

changeset baa5ec031980 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=baa5ec031980 description: MIPS: Implement the set_thread_area system call. diffstat: 1 file changed, 11 insertions(+), 1 deletion(-) src/arch/mips/linux/process.cc | 12 +++- diffs (29 line

[m5-dev] changeset in m5: MIPS: Fix decoding of the rdhwr instruction.

changeset d99f7b0ac614 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=d99f7b0ac614 description: MIPS: Fix decoding of the rdhwr instruction. diffstat: 1 file changed, 2 insertions(+), 4 deletions(-) src/arch/mips/isa/decoder.isa |6 ++ diffs (16 lines): diff -

[m5-dev] changeset in m5: MIPS: Implement the SE mode version of rdhwr.

changeset 4fc450d6a54e in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=4fc450d6a54e description: MIPS: Implement the SE mode version of rdhwr. diffstat: 1 file changed, 6 insertions(+) src/arch/mips/isa/decoder.isa |6 ++ diffs (17 lines): diff -r d99f7b0ac614

[m5-dev] changeset in m5: MIPS: Update stats for updated initial environm...

changeset 451ddd5d50d6 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=451ddd5d50d6 description: MIPS: Update stats for updated initial environment. diffstat: 12 files changed, 582 insertions(+), 590 deletions(-) tests/quick/00.hello/ref/mips/linux/inorder-timing/config

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

It looks like I forgot to update the Ruby version of the MIPS regressions after changing the process initialization code. I'll try to take care of that at some point today, but if anyone's in a hurry (or bored) it should be fine to just update them. Gabe Cron Daemon wrote: > * build/ALPHA_SE/

[m5-dev] changeset in m5: MIPS: Update the stats of the RUBY version of t...

changeset 9e14a8c76257 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=9e14a8c76257 description: MIPS: Update the stats of the RUBY version of the regressions. diffstat: 16 files changed, 71 insertions(+), 67 deletions(-) tests/quick/00.hello/ref/mips/linux/inorder-timi

[m5-dev] changeset in m5: SCons: Make --help reflect the arguments to scons.

changeset cdf3b0523858 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=cdf3b0523858 description: SCons: Make --help reflect the arguments to scons. The arguments were added to the global_sticky_vars Variables object after the basic help text was generate

Re: [m5-dev] FW: changeset in m5: util: make a generic checkpoint aggregator that...

This change seems to have broken the build for everything except Alpha (no regressions?). I don't like that #if THE_ISA. What is it doing, and why can't it be done in some Alpha specific body of code? Gabe Hsu, Lisa wrote: > > This is the last one. > > Lisa > > -Original Message- > From:

Re: [m5-dev] MIPS o3 unaligned store error

Unless I'm missing something, those aren't available in the interface instructions use to talk to the CPU (see exec_context.hh). Gabe nathan binkert wrote: > Why not use readBlob and writeBlob? > > Nate > > On Wed, Jan 20, 2010 at 2:48 AM, Gabriel Michael Black > wrote: > >> A structure mig

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

If --scratch means from scratch like I'm assuming it does, something doesn't seem to be working right. Gabe Cron Daemon wrote: > * > build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory > passed. > * > build/ALPHA_SE/tests/fast/quick/00.hello/alph

Re: [m5-dev] MIPS o3 unaligned store error

Hi Matt. Sorry no one has taken a look at this yet, at least that I'm aware of. We haven't forgotten you, but it might take a little while before we can get this taken care of. Gabe Matt DeVuyst wrote: > I fixed the problem. See the attached patch. > > For the case of writing 3 bytes to memory,

Re: [m5-dev] [PATCH] inorder/sim: add thread activation priority

I don't really know anything about the situation here, but is it possible to just call a function to take care of the thread activation at the end of the tick event? I'm making the assumption that every time a thread is activated a tick should have already happened for that instant. Gabe Korey Se

Re: [m5-dev] [PATCH 0 of 2] Updated: Timing translation and unaligned accesses

The original email and my own vague memories suggest these patches were sent out once, there was some feedback, and you fixed them up and sent them out again. Is that right? I looked through them fairly quickly and didn't see anything that seemed wrong. The majority of the changes are in O3, I thin

[m5-dev] ARM's IT instruction and speculative predecoder state

As I mentioned before, ARM has an IT instruction which choses a condition to predicate up to the next 4 instructions on. The particular condition and the number of instructions left to predicate are available in a control register and are set/saved/loaded to save context on interrupts and fault

[m5-dev] changeset in m5: Config: Fix fs.py's call to CacheConfig.config_...

changeset f2b4d8bea5d3 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=f2b4d8bea5d3 description: Config: Fix fs.py's call to CacheConfig.config_cache. diffstat: 1 file changed, 2 insertions(+), 2 deletions(-) configs/example/fs.py |4 ++-- diffs (15 lines): diff -r

Re: [m5-dev] changeset in m5: Config: Fix fs.py's call to CacheConfig.config_...

f code that are used verbatim probably more than they're used as examples, so it would be a good idea to actually test them. My fourth reaction was that these scripts seem overly complicated to me, and that probably makes mistakes like this a lot easier to make than is really necessary. Gabe Gabe

Re: [m5-dev] Runtime Value of Stats

I asked the same question a while ago. I don't remember the reason but there is one. Gabe Korey Sewell wrote: > Okay great, thanks Lisa. > > So the follow-up question for anyone inclined to answer is: Is there > ever a reason to have a "counter" variable and a "stat" variable? Is > there somethin

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

Cron Daemon wrote: > * build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/inorder-timing > FAILED! > * build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/inorder-timing > FAILED! > I don't know if anybody noticed these. There were a couple last week too, apparently. Since we have s

Re: [m5-dev] tests

> (Practically speaking, do we > support anything other than linux on any other ISA?) > Only supporting Linux doesn't mean the OS never changes. It would be nice to be able to test both 32 and 64 bits of Linux in both FS and SE, or even different configurations of each. This is especially true

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

I've thought about these sorts of hard to reproduce failures before, and thought maybe we should have the regressions periodically dump stats? That way we could tell roughly when something diverged. I don't know if that would actually tell us much, but it would tell us more and sounds to my naive e

Re: [m5-dev] [PATCH 07 of 31] m5: Fixed request read bug flagged by Valgrind

I wanted to fix it, but we never really found a way to do that, at least that everybody could agree on. In my opinion, the timing simple CPU needs a subtle but fundamental rework to avoid this class of bugs. Also, that'll take more time than I personally have available these days, so I'm not going

Re: [m5-dev] [PATCH] CPU: Make the CPU wait until initiateAcc finishes before calling completeAcc

It's been a while since I've looked at this, but I want to make sure I remember to respond so I don't want to wait until I have a chance to re-research all this. Isn't the problem that initiateAcc ends up calling completeAcc mid-function, that cleans up after the access, then initateAcc gets contro

Re: [m5-dev] [PATCH] CPU: Make the CPU wait until initiateAcc finishes before calling completeAcc

Reinhardt wrote: > Hi Gabe, > > On Sun, Mar 21, 2010 at 5:22 PM, Gabe Black wrote: > >> It's been a while since I've looked at this, but I want to make sure I >> remember to respond so I don't want to wait until I have a chance to >> re-research

Re: [m5-dev] testing infra for x86 support in M5

X86 support is enabled for M5, although isn't 100% complete or debugged. There are no x86 checkpoints or ways to generate them currently, but we do have a number of x86 regression tests. Those check the statistics of the simple atomic CPU, so if you were to use them directly you'd need to fake thos

Re: [m5-dev] SenderState

Steve Reinhardt wrote: > On Fri, Mar 26, 2010 at 10:32 PM, nathan binkert wrote: > >>> #1 sounds pretty good to me... 2 & 3 seem like overkill. I don't >>> think the overhead of the null pointer is that bad. >>> >> Ok, cool. I'll cook up a diff. >> >> I'm partial to doing 1,

Re: [m5-dev] SenderState

Steve Reinhardt wrote: > On Sat, Mar 27, 2010 at 12:20 AM, Gabe Black wrote: > >> What about one way packets that don't collapse back to the sender? Do we >> have any of those? Or do we always collapse back at least with the ack? >> > > I'm not su

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

So it doesn't get missed in the pile, this one failed. * build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/inorder-timing FAILED! Cron Daemon wrote: > * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby > passed. > * build/ALPHA_SE/tests/fast/quick/00.hello/

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

Those are good questions to answer because they point either to non-determinism in the CPU or host state leaking into the simulation. Another thing people suggested way back when when I was trying to fix something similar was to use netcat with tracediff to compare execution across two known differ

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

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 whe

Re: [m5-dev] [PATCH] Bug fix: Another branch predictor fix

There are some style issues with this code, although it looks like they might partially be holdovers from the original code. There should be spaces before and after the "="s, the "if", the ">=", and after the ")" and the ","s. "else" should be on the same line as the closing bracket of the if, and

Re: [m5-dev] [PATCH] Bug fix: Another branch predictor fix

Woops, sorry. No extra space before the if, just one after it. Also, if you're fascinated by our particular set of rules and want to learn more (or if you're just bored :) ), the actual style guide is here: http://m5sim.org/wiki/index.php/Coding_Style Gabe Gabe Black wrote: > T

Re: [m5-dev] [PATCH 0 of 3] Final squash patch

Hello again. As far as formatting your change seems to end up in the right place, but the steps in the middle probably aren't necessary. You should look at the qfold command as a way to combine these into one more direct patch. Gabe Maximilien Breughe wrote: > This is the patch I made for the squ

Re: [m5-dev] Review Request: Adding some new options to support TRIPS ISA

I'm not familiar with EDGE or TRIPS, but I'm very skeptical any changes would need to be made to the isa parser to support it. Please explain what your changes are for, and why you weren't able to use some other existing mechanism to get the same effect. The parser as is is actually very flexible a

Re: [m5-dev] Review Request: Adding a cpu model named simpleEdgeCPU into M5

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/14/#review2 --- This should be considered a first pass review which doesn't address every is

Re: [m5-dev] Review Request: ISA description files for TRIPS ISA

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/15/#review3 --- This is also a first pass review. I focused only on the ISA description files

Re: [m5-dev] Review Request: Make TRIPS binaries available

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/16/#review4 --- This change is pretty close to ok. If you fix up the things mentioned below,

Re: [m5-dev] Review Request: Make TRIPS binaries available

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/16/#review6 --- src/base/loader/elf_object.cc

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

Hi everybody. This is definitely a gigantic change, but one of the nice aspects of reviewboard seems to be that you can review whatever sized portion of the code you like, can come back later, and that everybody's comments accumulate. In retrospect it probably would have been easier to work through

[m5-dev] changeset in m5: X86: Finally fix a division corner case.

changeset abdcb0389716 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=abdcb0389716 description: X86: Finally fix a division corner case. When doing an unsigned 64 bit division with a divisor that has its most significant bit set, the division code would

[m5-dev] changeset in m5: Statetrace: Fix compile problems with the AMD64...

changeset 68195a20503b in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=68195a20503b description: Statetrace: Fix compile problems with the AMD64 version of statetrace. diffstat: util/statetrace/arch/tracechild_amd64.cc | 19 ++- util/statetrace/arch/tr

[m5-dev] changeset in m5: X86: Sometimes CPUID depends on ecx, so pass th...

changeset d9823ce926fa in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=d9823ce926fa description: X86: Sometimes CPUID depends on ecx, so pass that in. diffstat: src/arch/x86/cpuid.cc | 3 ++- src/arch/x86/cpuid.hh | 3 +

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

We'll check this in on Friday unless someone asks us to wait. Get your shots in now while there's still time! Gabe Gabe Black wrote: > Hi everybody. This is definitely a gigantic change, but one of the nice > aspects of reviewboard seems to be that you can review whatever sized

[m5-dev] changeset in m5: X86: Update the base aux vector X86 processes i...

changeset b8f2983a1c88 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=b8f2983a1c88 description: X86: Update the base aux vector X86 processes install. diffstat: src/arch/x86/process.cc | 28 +--- src/arch/x86/process.hh | 4 2 files cha

[m5-dev] changeset in m5: X86: Update stats for the updated auxilliary ve...

changeset e46d048f7e69 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=e46d048f7e69 description: X86: Update stats for the updated auxilliary vectors. diffstat: tests/long/00.gzip/ref/x86/linux/simple-atomic/config.ini |2 +- tests/long/00.gzip/ref/x86/linux/simp

Re: [m5-dev] POWER_FS - PCI and IO information

Hi, sorry if my earlier reply was a bit redundant with Ali's here. It ended up in my spam filter somehow. Anyway, one nice thing about x86 systems is they all have the same core platform that's been the same forever, and it's well understood and documented to the point that I could find some useful

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

There have been failures the last couple days. I looked at one of them, and simerr had Traceback (most recent call last): File "", line 1, in File "/z/m5/regression/zizzer/m5/src/python/m5/main.py", line 359, in main exec filecode in scope File "tests/run.py", line 70, in execfile(

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

on changes or a network issue. I did forget to update the X86_SE ruby stats though, so that explains one of the failures. Gabe Gabe Black wrote: > There have been failures the last couple days. I looked at one of them, > and simerr had > > Traceback (most recent call last): > File &

[m5-dev] changeset in m5: X86: Update the stats for the new aux vectors i...

changeset b9480b90cf18 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=b9480b90cf18 description: X86: Update the stats for the new aux vectors in the ruby regression. I forgot to turn on ruby when updating the stats before. diffstat: tests/quick/00.hello/ref/x8

[m5-dev] changeset in m5: Merge.

changeset 24379f92cc10 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=24379f92cc10 description: Merge. diffstat: src/base/stats/visit.hh | 5 - src/kern/tru64/tru64.hh | 2 +- src/sim/syscall_emul.hh | 6 -- 3 files changed, 5 insertions(+), 8 deletions(-)

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

> On 2010-05-08 11:08:07, Steve Reinhardt wrote: > > Overall I'm kinda disappointed that most of the decode ended up in C++ and > > not in the ISA description language (I know the latter would have required > > some extensions)... now that it's in place and (presumably) working though, > > I g

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

:FaultBase seems more consistent with other naming than > > FaultVals:Fault; I'm curious what motivated the change. > > > > Gabe Black wrote: > It looks like I made that change. I don't really remember my motivation > (a danger of putting off reviews for so

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

> On 2010-05-08 11:08:07, Steve Reinhardt wrote: > > src/arch/arm/isa/formats/data.isa, line 41 > > <http://reviews.m5sim.org/r/20/diff/1/?file=206#file206line41> > > > > Is there a reason we can't use predefined bitfields here (and a ton of &g

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

> On 2010-05-11 14:15:10, Steve Reinhardt wrote: > > src/arch/arm/isa/formats/data.isa, line 1138 > > > > > > It looks like cases 1 & 3 (and 9 and 0xb) are identical; right? If so, > > I think they should be merged; getting ri

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

> On 2010-05-08 11:08:07, Steve Reinhardt wrote: > > src/arch/arm/insts/mem.hh, line 252 > > <http://reviews.m5sim.org/r/20/diff/1/?file=181#file181line252> > > > > seems like this should go in a .cc file > > Gabe Black wrote: > Wouldn't t

[m5-dev] changeset in m5: X86: The logic that handled the recently fixed ...

changeset 56bbefb997fe in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=56bbefb997fe description: X86: The logic that handled the recently fixed corner case for div wasn't quite right. ___ m5-dev mailing list m5-dev@m5sim.org ht

[m5-dev] changeset in m5: X86: Actual change that fixes div. How did that...

changeset c52c581277bf in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=c52c581277bf description: X86: Actual change that fixes div. How did that happen? diffstat: src/arch/x86/isa/microops/regop.isa | 8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diffs

[m5-dev] changeset in m5: X86: Make the cvti2f microop sign extend its in...

changeset ff2321547ca3 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=ff2321547ca3 description: X86: Make the cvti2f microop sign extend its integer source correctly. The code was using the wrong bit as the sign bit. Other similar bits of code seem to b

[m5-dev] changeset in m5: SPARC: Implement the version of movcc that uses...

changeset e4c5fbbc8633 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=e4c5fbbc8633 description: SPARC: Implement the version of movcc that uses the fp condition codes. diffstat: src/arch/sparc/isa/decoder.isa | 28 +++- 1 files changed, 27 ins

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

:FaultBase seems more consistent with other naming than > > FaultVals:Fault; I'm curious what motivated the change. > > > > Gabe Black wrote: > It looks like I made that change. I don't really remember my motivation > (a danger of putting off reviews for so

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

> On 2010-06-01 11:31:08, Nathan Binkert wrote: > > src/arch/arm/miscregs.cc, line 49 > > > > > > How often does this happen? Is there nothing more efficient than this > > insane implementation? A table lookup perhaps? > > Ali

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

Yes, I was going to suggest that. ~300 emails, and then the "I still can't deliver this" emails forever after. Gabe Ali Saidi wrote: > Unless someone has an issue with it, I'm planning on disabling the email > trigger to save everyone ~300 emails. > > Ali > > > > On Jun 1, 2010, at 3:06 PM, Ali

Re: [m5-dev] ARM commits

That's likely from the same file being copied/moved in the process of splitting it up. The single decoder.isa was split into an ARM and thumb part, for instance. I wouldn't be too alarmed by that unless something isn't working properly. Gabe nathan binkert wrote: > I just did a pull and got these

Re: [m5-dev] ARM commits

nathan binkert wrote: That's likely from the same file being copied/moved in the process of splitting it up. The single decoder.isa was split into an ARM and thumb part, for instance. I wouldn't be too alarmed by that unless something isn't working properly. Can you just double check that

Re: [m5-dev] assertion bug in TimingSimpleCPU

Timothy M Jones wrote: > Hi everyone, > > On 06/06/2010 18:59, Ali Saidi wrote: >> >> On Jun 6, 2010, at 4:53 PM, Steve Reinhardt wrote: >> >>> I've only thought about this briefly, but here are a few quick >>> reactions: >>> >>> - PowerPC has updating ld/st instructions too. How are these handled

Re: [m5-dev] Linux Kernel/Boot Time for X86_FS

Hi Joel. I'm happy to hear it's booting for you! I've already translated the patches over to x86 and they do help boot time, but I couldn't tell you off hand where they went. I think we have a mercurial repository with those in it someplace. When you say "bring up", does that include init scripts?

Re: [m5-dev] Linux Kernel/Boot Time for X86_FS

nathan binkert wrote: >> Hi Joel. I'm happy to hear it's booting for you! I've already translated >> the patches over to x86 and they do help boot time, but I couldn't tell >> you off hand where they went. I think we have a mercurial repository >> with those in it someplace. >> > > I just want

Re: [m5-dev] Linux Kernel/Boot Time for X86_FS

Gabe Black wrote: > nathan binkert wrote: > >>> Hi Joel. I'm happy to hear it's booting for you! I've already translated >>> the patches over to x86 and they do help boot time, but I couldn't tell >>> you off hand where they went. I thin

Re: [m5-dev] assertion bug in TimingSimpleCPU

Gabe Black wrote: > Timothy M Jones wrote: > >> Hi everyone, >> >> On 06/06/2010 18:59, Ali Saidi wrote: >> >>> On Jun 6, 2010, at 4:53 PM, Steve Reinhardt wrote: >>> >>> >>>> I've only thought about this

Re: [m5-dev] assertion bug in TimingSimpleCPU

Steve Reinhardt wrote: > On Sun, Jun 13, 2010 at 12:04 PM, Gabe Black wrote: > >> Gabe Black wrote: >> >> I just thought of another, more important drawback. In an in order >> pipeline, the writeback will take up an extra pipeline stage, >> effectively addi

Re: [m5-dev] Configuration file for building Linux x86

Here's one for a 2.6.22.9 SMP kernel. I have other ones that are more recent, but they may not have SMP support turned on. I can give you those as well if you'd like. Gabe Gabriel Michael Black wrote: > You shouldn't really need any special .config options, although use > more adventurous setting

Re: [m5-dev] flyspray

Steve Reinhardt wrote: > I went through and closed the tasks that were obviously obsolete from > my perspective. Nearly all of the rest look plausible to me, though > many are outside my area of familiarity (e.g., the x86- and > SPARC-specific ones). Perhaps the reality is that, as much as we'd >

Re: [m5-dev] startup issues

nathan binkert wrote: >> 3. Add a phase to the initialization process to make this cleaner. >> Possibilities: >> a. Add a second-stage init() call in step 1d so that we can keep >> the code in question occurring after the current init(), but move it >> before the checkpoint restore. >> b. Add a

Re: [m5-dev] startup issues

nathan binkert wrote: >> Stepping back a bit, part of the complexity stems from the interface >> between the user's simulation script and the core code: when you call >> instantiate(), there's no indication whether or not you'll be >> restoring from a checkpoint, so we have to wait for the call to

Re: [m5-dev] startup issues

Steve Reinhardt wrote: > On Wed, Jun 23, 2010 at 10:48 PM, Gabe Black wrote: > >> The entire SimObject startup process has always been a little mysterious >> to me as far as what all the steps are and what they're for, and it >> sounds like it's getting more

[m5-dev] changeset in m5: X86: Fix div2 flag calculation.

changeset 6a854784be4f in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=6a854784be4f description: X86: Fix div2 flag calculation. diffstat: src/arch/x86/isa/microops/regop.isa | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diffs (12 lines): diff -r 1b1f8f32

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

I don't think I have. Maybe they're being sent but squashed as spam somewhere? Gabe Steve Reinhardt wrote: > Did anyone else get a regression email since this one? It's the last > one I received. The regressions are still running; it looks like it's > just the mail that's not getting sent out.

Re: [m5-dev] SPARC_SE and InOrderCPU

Microcode isn't part of the architecture so it won't be in that manual. It's just how we've chosen to implement a few instructions, specifically block loads and stores. I don't think the problem you're seeing has anything to do with microcode, though. Gabe Eberle wrote: > I can't find the specifi

Re: [m5-dev] SPARC_SE and InOrderCPU

I think we should figure out whether eaComp should or shouldn't exist first. Currently it's only used in InOrder. Why is it necessary instead of using the other, existing mechanisms? I vaguely remember having this conversation before, but I don't remember who said what, what was decided, or if we e

Re: [m5-dev] X86_FS vtophys implementation

Yeah, I skipped implementing that so far. The reason the table walker is the way it is is that it needs to actually cooperate with the memory system and do real loads/stores, honor timing, etc. For functional accesses you should be able to write a simpler implementation that just uses its own funct

Re: [m5-dev] Review Request: SimpleCPU: Allow Simple CPUs to warm a branch predictor by creating a pointer

I haven't looked at the code yet, but I'm wary of unsimplifying the simple CPU. It's been headed that way anyway, but just as much as functionally correct execution required. I'd like to see us resimplify it somehow instead. I'm not familiar with SMARTS, but would you be able to have some short lea

Re: [m5-dev] Review Request: Power: Provide a utility function to copy registers from one thread context

I'm replying on m5-dev instead of review board since this is wandering away from the topic of Timothy's code. Please let me know if we're trying to keep things on there anyway. I've thought before that it would be nice to have generic versions of utility and other functionality as well. A class is

[m5-dev] Loading/storing oddly sized memory blobs from instructions

In ARM's SIMD instruction set extension Neon, there are some instructions which can load or store 3 of something, and that something can be 1, 2, 4, or 8 bytes. To implement this properly, I'm planning to add readBytes and writeBytes functions to the various ExecContexts which would load/store some

Re: [m5-dev] Loading/storing oddly sized memory blobs from instructions

Steve Reinhardt wrote: > On Sat, Jul 10, 2010 at 11:37 PM, Gabe Black wrote: > >> In ARM's SIMD instruction set extension Neon, there are some >> instructions which can load or store 3 of something, and that something >> can be 1, 2, 4, or 8 bytes. To implement t

Re: [m5-dev] sparc64-linux writev syscall patch / unhandled trap

Your patch looks reasonable. You likely already did this, but since you're working with m5-stable which is fairly old, please be sure to check the development repository just in case your problem was already fixed. I just checked and this isn't there either, but that's one of the hazards of using m

Re: [m5-dev] a question on CPU assertions

Here's more or less what's going on as far as the register index. The load microop needs to store into register 1, and it needs to be sure it stores into the version visible from the "user" mode. It does that by applying the intRegInMode function which shifts the register index 1 by MODE_USER * the

Re: [m5-dev] cleaning up TimingSimpleCPU

Steve Reinhardt wrote: > All the discussion of different extensions to TimingSimpleCPU got me > thinking again about what a mess it is. I walked through the code > with Brad & Joel a few weeks ago, and it's still the same basic > structure of everything being driven by callbacks, with numerous cas

Re: [m5-dev] possible contributions to M5

Jiayuan Meng wrote: > > > > 2. SIMD cores: Based on TimingSimpleCPU. > This sounds pretty interesting too. Does the ISA matter much, or do > you think it could be pretty generic? Did you add new instructions to > do things? > > > Yes, I amended the Alpha ISA and added two instruc

Re: [m5-dev] cleaning up TimingSimpleCPU

Gabe Black wrote: > Steve Reinhardt wrote: > >> All the discussion of different extensions to TimingSimpleCPU got me >> thinking again about what a mess it is. I walked through the code >> with Brad & Joel a few weeks ago, and it's still the same basic >&g

[m5-dev] changeset in m5: ARM: Adjust the FP_Base_DepTag to be larger tha...

changeset fbc62b421fa0 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=fbc62b421fa0 description: ARM: Adjust the FP_Base_DepTag to be larger than the largest int reg index. diffstat: src/arch/arm/registers.hh | 2 +- src/arch/arm/types.hh | 3 ++- 2 files change

Re: [m5-dev] a question on CPU assertions

case MODE_ABORT: >> return INTREG_ABT(reg); >> case MODE_UNDEFINED: >> return INTREG_UND(reg); >> * default:* >> *panic("Flattening into an unknown mode.\n&

<    1   2   3   4   5   6   7   8   9   10   >