On Wed Feb 17 14:51 , Onno Kortmann sent: >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
Note that we normally deal with three address spaces: "SRAM", flash and EEPROM. R0-R31 and the "IO" registers are in the "SRAM" address space. The flash and EEPROM address spaces are pretty much flat. The "SRAM" address space is a lot more interesting. >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. This seems rather like you will continue going your own way unless the savannah repository is converted to git. I don't know that I would want to move to git. So far, even with hand-holding, I haven't managed the first step. Subversion would be okay. --- Michael Hennebry [email protected] "War is only a hobby." ---- Msg sent via CableONE.net MyMail - http://www.cableone.net _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
