On Jan 28, 2012, at 3:00 AM, Gabe Black wrote:

> 
>>> My discussion of the general compile-time mechanism is just to emphasize
>>> that the maintenance of this one aspect of the current SE/FS difference is
>>> a stopgap replacement for this alternate ideal, not a perpetuation of the
>>> now-meaningless distinction that Gabe has worked so hard to eradicate, so
>>> that he doesn't accuse me of bitterly clinging to the past...
>> Ok, but I'd really hate to see this delay Gabe long enough that we
>> don't ever get it into the tree.  Gabe, do you think it'd be easy to
>> cook up what Steve is talking about?  (Or does it already work in your
>> tree?)
>> 
> 
> I'll try adding an option that leaves out the devices since I assume
> that's where the extra time is coming from. I'm thinking if you set
> NO_DEVICES on the scons command line it will leave the devices out of
> the build. That won't be set by default on anything since the same build
> is used for both SE and FS and it doesn't make sense as a default, but
> if you're using it for SE style stuff and build time is affected enough
> for you to find out about that option, then it'll be available. There
> may be complications so no promises. It may also not close recover the
> build time, but I expect it will.
I think that adding these sorts of things is going to create more confusion 
that it's worth. We're going to have people who compile with NO_DEVICE and 
don't understand why they can't run full-system code (or the random error we're 
going to produce about not being able to create a simobject) and we're going to 
have a group of people who don't know NO_DEVICE exists and so they never use 
it. A 30% compile time increase the first time you compile "SE" mode doesn't 
seem bad. The device models shouldn't need re-compile, so any further 
development for SE activities shouldn't effect them. This simples something 
that confuses a reasonable fraction of users (What is SE and FS?) and speeds up 
compiles tremendously for those of us who compile multiple binaries frequently. 

Ali

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to