I think HasTSO, NeedsTSO, IsTSO, TSOsBFF, whatever, is fine, since all
of them indicate TSO is being turned on.
The idea that when I want generalization it's for generalization's
sake implies that I have no justification other than it's just what
trips my trigger is nonsense and extremely dismissive. You can
disagree, you may be right, but my arguments should be taken just as
seriously as anyone else's.
Branch delay slots are actually a good example where turning things
into an on/off switch is an oversimplification that does more harm
than good. There are delay slots, annulled delay slots under different
circumstances, micropcs, delayed micropcs, speculative decode state,
etc. which were either not handled at all, handled incorrectly, or
handled poorly even with dedicated machinery in place. There are
10,000 shades of gray, and you can't just pick 3 and expect everybody
to be happy.
I think putting constants or bools into isa_traits.hh is generally
bad. Some of the time they don't make any sense in most of the ISAs
and have to be set to whatever somebody guesses is the most inert
setting. Sometimes we end up with multiple copies of the same thing
because nobody remembers what's already in there. You have to go
spelunking to figure out how a constant is used, and even then it
might not be consistent. There's no good way to know a constant isn't
needed any more and to get rid of it. There's no structure, just a big
wad of gunk doing 100 different things nobody remembers. There are a
few justified cases for things to go in isa_traits.hh, but I think
most of the time things are put there because it wasn't obvious where
they should go, even though there was probably a better place if
somebody looked hard enough.
The reason I don't like putting this in isa_traits.hh is because for
most of the ISAs it's a NOP and just causes clutter. I don't want to
beat Nilay over the head about it since it's not the end of the world,
but it's contributing to the clutter in that file.
If the a, b, c, d, thing I mentioned would be too much of a pain
because of dependencies (I can see that happening), weird checks that
need to happen, etc., then it makes sense not to do that. I would
still prefer this to be a parameter if nothing else for the far off
day when all the ISAs are compiled into one binary (hopefully without
templates that would quintuple the binary size), but I won't have a
heart attack if it isn't. Just remember when you go to put a new
constant in isa_traits.hh that it's probably the wrong thing to do and
you should reconsider your design.
Gabe
Quoting Nilay Vaish <[email protected]>:
I declare Steve to be the winner!
--
Nilay
On Mon, 9 Jan 2012, Steve Reinhardt wrote:
HasTSO is acceptable to me, but if we're looking for alternatives, we could
do NeedsTSO instead (since in a sense the consistency model is a
requirement the ISA puts on the memory system).
Steve
On Mon, Jan 9, 2012 at 4:34 PM, Ali Saidi <[email protected]> wrote:
That is fine. I can see arguments both ways, but go for it.
Ali
On 09.01.2012 18:30, Nilay Vaish wrote:
Ali, are you sure that 'an
ISA is total store order' is grammatically
correct? I chose hasTSO on
purpose, since I feel 'an ISA has total store
order' is correct.
--
Nilay
On Tue, 10 Jan 2012, Ali Saidi wrote:
I'm neutral
on this, either way is fine, but I think the name HasTSO isn't ideal. An
ISA is TSO, but I don't know that it has TSO. Ali
_______________________________________________
gem5-dev mailing
list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
