Simulavrxx revival, was Re: [Simulavr-devel] [patch #7079] Trace fixes and better memory access

[Onno Kortmann]

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