# HG changeset patch
# User Nathan Binkert <[EMAIL PROTECTED]>
# Date 1213057781 25200
# Node ID ac6a6b3ef9362731553138e72974cd02f4c4169c
# Parent ad5af63d60375b99e633ef71ef687bacab0c8a82
eventq: new eventq data structure. The new data structure is singly
linked list sorted by time and priority.
# HG changeset patch
# User Nathan Binkert <[EMAIL PROTECTED]>
# Date 1213057781 25200
# Node ID ad5af63d60375b99e633ef71ef687bacab0c8a82
# Parent a31128ea7b6f9bc3242898efc2f5689db2ca6d06
eventq: Clean up the Event class so that it uses fewer bytes. This
will hopefullly allow it to fit in a cache
Since I'm hoping to have the repo all set soon, I figured I'd start
sending things out.
This my new event queue data structure. It is considerably faster (3x
simulation speed for me) for systems that make heavy use of multiple
events at the same tick/priority. Stats will change a bit because
eve
I agree. There are three different naming mechanisms that I'm aware of
we need to work with, file names for the headers, python names which go
in modules, and C++ names which go in namespaces. If all names can be
hierarchical, which I think they should be, then there needs to be a way
to map the na
One thing to try maybe is Intel CC. Perhaps their linker is faster? or
do they use ld? You're probably running into a I/O limitation on your
laptop not a CPU problem.
Ali
On Jun 9, 2008, at 2:02 PM, nathan binkert wrote:
> Yeah, that makes sense. We don't really have subsystems with local
> So this would be the PCI bus support in the north bridge for instance?
> Should I just arbitrarily pick a chipset and implement that, or is there
> something more generic?
I think that there's really only one interface for this that really
matters. On alpha, there were lots of north bridge inte
Yeah, that makes sense. We don't really have subsystems with local
symbols. That said, is it faster to incremental link strip and then
finish the link? I'm just curious if there are any symbols that we
can automatically strip.
Then again, I build debug most of the time and you wouldn't want to
I would look at the kernel and see exactly what it's trying to probe
and start with just returning the values it expects and see how far
that gets you (The ISAFake device is especailly useful for this sort
of thing). I imagine there is something more generic, but the kernel
source will prob
Whoever gets to it. If you don't want to do it instead of the simple
patch you wrote, we can put it on the todo list. In general, that
code is getting pretty messy and needs some TLC.
On Mon, Jun 9, 2008 at 11:21 AM, Gabe Black <[EMAIL PROTECTED]> wrote:
> That makes sense to me. I can do that
That makes sense to me. I can do that at some point or if you'd rather
that'd be fine too.
Gabe
nathan binkert wrote:
>>> It won't, but if you use the attached patch it seems to. Let me know if
>>> it looks good and I'll tack it onto my queue.
>> Patch looks good.
>
> Actually, does it make sens
I've done some reading online and it doesn't appear that incremental
linking will cut down on the link time much at all. Doing it in
smaller chunks doesn't help if all the symbols end up being exported
at the end. The two ways to speed it up are to (a) not include any
debugging information
So this would be the PCI bus support in the north bridge for instance?
Should I just arbitrarily pick a chipset and implement that, or is there
something more generic?
Gabe
nathan binkert wrote:
>> So as it says, it's checking bus 0 device 0 for a host bridge. Do we
>> have a way to set that up?
>> It won't, but if you use the attached patch it seems to. Let me know if
>> it looks good and I'll tack it onto my queue.
> Patch looks good.
Actually, does it make sense to get rid of cxx_namespace and just make
it part of cxx_type? If you're going to do a split anyway, why bother
to have two
> What about making Enums recognize cxx_namespace too? That would be
> pretty handy although I'm not sure how feasible. There seems to be a
> global list of them that would probably get confused if there was more
> than one with the same name, even if they were in separate modules.
In general, I d
> It won't, but if you use the attached patch it seems to. Let me know if
> it looks good and I'll tack it onto my queue.
Patch looks good.
> Also, is there a solid
> reason the create functions can't end up in a namespace other than the
> global one? I'm ending up with some pretty horrible names
Few comments.
1) I like this idea.
2) Linux explicitly exports symbols outside of an object. This seems
like it would be a pain.
3) Anonymous namespaces aren't obscure. Maybe there's a way to remove
these with strip.
4) It shouldn't be hard to get SCons to support this sort of thing.
Nate
On
I quickly scanned the SCons documentation and couldn't find anything
built in, but clearly the kernel does it so it can be done.
Ali
On Jun 9, 2008, at 5:48 AM, Gabe Black wrote:
> Is there some way we can make m5 link incrementally, or in other
> words
> link subsystems together indep
> So as it says, it's checking bus 0 device 0 for a host bridge. Do we
> have a way to set that up? I can short circuit that by filling in one of
> the tables from the BIOS a little more, but if this is something I'm
> going to need to do anyway I'd rather do that.
I believe that bus 0 is on the h
Is there some way we can make m5 link incrementally, or in other words
link subsystems together independently and then as units with each
other? The final linking step seems to take a long time with ld at 100%
cpu usage. That makes sense when you consider it's linking a screen and
a half of
What about making Enums recognize cxx_namespace too? That would be
pretty handy although I'm not sure how feasible. There seems to be a
global list of them that would probably get confused if there was more
than one with the same name, even if they were in separate modules.
Gabe
Gabe Black wrote:
It won't, but if you use the attached patch it seems to. Let me know if
it looks good and I'll tack it onto my queue. Also, is there a solid
reason the create functions can't end up in a namespace other than the
global one? I'm ending up with some pretty horrible names trying to make
sure everythin
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/al
22 matches
Mail list logo
