Hi, > (Remaining changes are not user-visible.) > > These were found while adjusting the code for different handling of memory > access: reading/writing (after this patch) goes through device first. (I > have to tinker with it and RWMemoryWithOwnMemory would be ugly.) > > pros: > * nicer ctors > * easier peeking into simulavr while debugging > * smaller DecodedInstruction instances (by ~3*4B) > * reduced cache pressure > * allows more efficient (cache friendly) storage of data memory (not yet in > this patch) > * less chance for wrong *::Trace() code or wrong X,Y,Z read > > cons: > * uglier *::operator() > * 1 more hot field in AvrDevice > * unaligned access to fields in instructions I like the general idea of having methods to access the rwmem array, but did you really benchmark your code for performance?
Also, I like to point out that your patch to avrdevice.* conflicts with Thomas' changes and he implemented the access methods as far as I see as one single one for each direction, "GetRWMem" and "SetRWMem". I have not a strong personal opinion on either one, but I think that we either need a merged interface supporting all ways of accessing (per SRAM, per IO and per RWMEM offset) or proceed with one implementation. This boils down to the forking problem here and git vs. SVN. So... asking all people around here: How do feel about our (Thomas' and mine) repo? We are at the point where we're sufficiently diverged from the main code to be incompatible for quite a lot of patches. But I think we ARE better than CVS HEAD. Really. Please. Look at it. I suggest that someone of the admins gives Thomas, Petr and me full access to savannah, let us replace the svn with a newer git repo, let us update the web site (at least with a short description that development is ongoing, I volunteer for this short website update, just having the date 2010 on there would help) and get simulavrxx going again. An ages-old website puts off potential contributors and users efficiently. There are patches accumulating in the tracker with noone really caring, other FOSS simulator projects for AVR are appearing (and IMO combined efforts give a better single simulator) and our patches are not even really discussed here. This is not good. And, yes, git and a more accepting and open policy for development would help a lot. I am sorry to say this, but even I with a still limited understanding of simulavrxx have found a lot of stupid bugs and places for improvements, though I like the C++iy architecture Klaus gave us. The code is in development stage. So the development process should be more open. And with git, for a possible stable branch, we could be a lot more conservative for that one. So... opinions? Let's get this going again! Best regards, Onno _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
