On 06/12/11 16:29, Steve Reinhardt wrote: > On Sun, Jun 12, 2011 at 1:05 AM, Gabe Black <gbl...@eecs.umich.edu> wrote: >> 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. > I think originally we supported memory accesses for any operand type > you could define, but that stopped being true once you made the > definitions extensible. My immediate concern is just to make sure > that switching from the old explicit sign extensions to some implicit > sign extensions that happened as a side effect of C type conversions > is really doing the right thing, but having a cleaner way of doing > memory accesses of arbitrary types is a good idea. > >> 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. > That sounds interesting, but seems like overkill... I just looked at > the SimpleCPU code, and as far as I can tell, the memory access type > (the arg type for read() and write()) is only used for two things: to > determine the size of the access, and to control the data type in the > InstRecord type for exec tracing (basically this is mostly setting the > data_status enum, but also using the proper double vs int field in the > data union). The actual type clearly doesn't matter at all for the > first, and only a subset of types are supported for the second.
There are actually three things, the third is to handle endianness. This is important if we delegate endian swapping to the read and write functions which we currently do, and helps when printing out what loads and stores returned at the CPU level. You get the same information, it's just easier to look at since it's a number and not a string of bytes. Moving that into the ISA desc would be feasible, and you could make a convincing argue that's where it should be in the first place. If ARM is configured to do loads/stores in the "other" endianness (which we support) then values could be swapped on the way in and then re-swapped before being used. The idea of non-byte sized values in memory and the endianness of them of is an ISA level concept. Other non-byte sized values like PCI registers are another story, of course, but that's a whole other issue. > The original idea with the templates was that they might permit faster > implementations for functional CPU models that communicated directly > with memory. However, if anything we've gone in the other direction > by implementing these templates in terms of readBytes() and > writeBytes(). > > So my general feeling is that if we want to make significant changes > to this interface, I'd be more inclined to streamline it and have the > generated ISA code call readBytes() and writeBytes() directly with a > size and some additional info to make exec tracing work (which should > get rid of the templates entirely, I think) rather than expanding the > template interface. Then the burden of converting from an untyped > sequence of bytes to whatever the ISA wants could be done entirely in > the ISA definition, which seems like a good place for it. Does that > make sense? Do you think it's feasible or worthwhile? I think that makes sense, although the devil is in the details as always. For memory in traces, it would be nice to have it endian corrected, but it wouldn't necessarily have to be. We could just print out each byte one at a time and have the understanding that it's a blob of memory, low addresses on the left. Or at least I think we could do that... >> 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. > We discussed this a long long time ago (when we first started > distributing the code, IIRC), and while it does have the advantages > you describe, the cost of further wrangling with lawyers is basically > not worth it IMO. Maybe if we started a new project from scratch we > would consider it, but the horse has left the barn for gem5, I think. Are you talking about copyright assignment, or moving the copyrights out of the file and then referring to them? Copyright assignment would be a big deal, and I can see how it isn't necessarily worth it. I like the other idea, though, because then there would only be one unique copy of each version of the license (no need to check for subtle differences) and we'd get away from the first screenful or two of text in every file being boilerplate license. We'd cut many thousands of lines of text from our source without actually changing anything. One objection in the past was that the license is less attached to the source, but we'd still refer to it and say it's copyright Foo, provided under license Bar. Also the license would be less isolated and harder to tamper with on a per file basis. Gabe _______________________________________________ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
