Hi Steve,
I agree it would great to get some organization there. I had been just
treating that as literally a "dump" for things that all CPU models need.

My theory to clean it up would be to add a "common" folder similar to how is
in the src/configs directory. Then in the common folder place a directory
called "trace" and a directory called "components" and also a directory
named "base" for all the things that are used as base-classes. My theory for
a clean way would be so that src/cpu directory doesnt have any files in it
accept SConscript type stuff and then the code is all in other special
subdirectories.

But, that's just how I would like to view things.

On Fri, Apr 10, 2009 at 12:18 PM, Steve Reinhardt <[email protected]> wrote:

> It would be nice to try and organize these shared files rather than just
> throwing them all in the src/cpu directory... that dir is already getting a
> little crowded.  IMO, the only files that really belong there are ones that
> describe common base classes (BaseCPU, ThreadContext, etc.).  How about a
> subdir like "components" for things like these shared branch predictors?
>
> It would also be nice to put the instruction tracing stuff in a separate
> place; a different subdir of src/cpu makes sense to me, though seeing that
> some of it has already been migrated to sim, I'm not so sure... seems to me
> it should be all under src/sim or src/cpu, but not arbitrarily split between
> the two.  This is a separate topic from Korey's changes though.
>
> Steve
>
>
> On Fri, Apr 10, 2009 at 8:15 AM, nathan binkert <[email protected]> wrote:
>
>> It's about time that this was done.  ozone used the predictor too and
>> it was cumbersome in the SCons code.
>>
>> Anyway, you did a move here, but this isn't being recorded because
>> you're not generating git style diffs.  If you could add:
>> [diff]
>> git = 1
>>
>> to your .hgrc, that will fix the problem for the future.
>>
>> You should refresh all of your diffs once you've added that flag.  I'm
>> pretty sure that this won't find the move and that you'll have to redo
>> the move to get it right.  Are there any other moves that you've done.
>>
>>  Nate
>>
>
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
>


-- 
----------
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science & Engineering
University of Michigan
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to