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. http://www.boost.org/users/license.html Gabe _______________________________________________ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
