On 06/04/11 09:32, Steve Reinhardt wrote:
> On Sat, Jun 4, 2011 at 1:57 AM, Gabe Black <gbl...@eecs.umich.edu> wrote:
>> To clarify, is this signed/unsigned issue something we need to deal with
>> before this patch goes in, or can it be dealt with separately later?
> I'd like to see it handled before the patch is committed, mostly
> because I'm still not 100% convinced that these changes don't break
> something.  Also when something gets deferred like this there's always
> the uncertainty of when/if it's going to get taken care of... nothing
> personal, I'd feel the same way if it was my own patch.
> Steve
> _______________________________________________
> gem5-dev mailing list
> gem5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/gem5-dev

I was thinking about this today, and if we expand the read/write
functions to handle signed types too, we're really just expanding the
arbitrary set of types they can handle, not removing the limitation that
you have to stay within those types which is what I think you don't like.

Instead of extending what we already have as far as explicit
instantiation, it would be nice to have a more automatic mechanism where
we'd just feed a list of types and a template (you can pass templates as
template arguments, sort of like function pointers but for templates)
and have some widget that cranks out the actual instantiation without so
much copy and paste coding. Some Googling indicates that Boost already
does this with some macros it has for working with sequences. I'm
looking into that more, and I'm thinking it would be best to figure out
how they did it and then make our own, rather than introduce a great big
new dependency.

Combining that with the first point, I think a nice solution would be to
have the ISA parser spit out a list of types that read/write need to
support in whatever form is necessary (preliminary reading suggests a
#define) and then have the CPU models all feed that into the
instantiator widget to get the versions they need. Then we'd get exactly
the functions we need and cut out a bunch of repetition in the source.
This would be at the reasonable cost (in my opinion) of some additional
complexity, although in some ways it would trade one type of complexity
for another.

Also, while looking for information about Boost (in progress right now)
I found their page where they talk about their license (link below).
Looking through it, there are some ideas there which seem relevant to
gem5. Specifically, I like the idea of a single license for everything,
perhaps involving assigning copyright to a neutral body like a gem5
foundation or something, and then just referring to it in the actual
source files. That would get rid of lots of redundant text, and they
make a good point that all that text is the sort of thing lawyers might
get their underwear in a bunch over. There may be (but isn't
necessarily) subtle variation on a file by file basis, and it's probably
a lot more work to go through if somebody ever needed to do that.


gem5-dev mailing list

Reply via email to