Hi Folks,
On Sun, 18 Jul 2010 10:46:38 -0400, Korey Sewell <ksew...@umich.edu> wrote:
That seems odd... I assume you're suggesting that Tim switch the
InOrderCPU to pass the PC instead, right?
Yep, I'm suggesting that this should be updated.
Tim, you'll want to edit the code fetch_seq_unit.cc, execution_unit.cc,
and
branch_predictor.cc to make sure that the PC gets passed throughout
instead
of the nextPC.
Ok, thanks for that Korey.
> Also, the BTB accesses use the asid instead of the tid (to accomodate
> multithreading) so please dont remove that.
I'm confused... are you trying to let threads that run in the same
address space all share the same BTB entries?
Yes!
That might actually be
a good idea, but I don't know that any real CPUs work that way. (Not
that I have intimate knowledge, I'd just be surprised... the ASID
generally has a lot more bits than the TID, esp. in x86 where the ASID
is really just the page table base pointer.)
Yes, as you might've guessed, I ran into some situations where the BTB is
becoming useless because of the amount of threads thrashing the entries
when
really the entries could be shared within each other.
So do you suggest that we just use the "tid" instead of the "asid" for
BTB
accesses to try to be more realistic for a general purpose processor
simulation?
It would seem that there would be something for this in modern CPUs to
help
aid "the plight" of multithreaded programmers....Although, If you assume
that the majority of programs are multiprogrammed I guess this "feature"
would only be useful for more application specific CPUs.
I'm not sure if there could be some type of BTB remapping for when
hardware
threads are of the same asid or maybe some type of allocation of BTB
entries
per thread, but it would be interesting to see what (if anything) people
do
for this.
So, after all this, which version do you want me to implement? TID or
ASID? I'll have a go at either.
Cheers
Tim
--
Timothy M. Jones
http://homepages.inf.ed.ac.uk/tjones1
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
