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

[Petr Hluzín]

Hi

(Second try, accidentally not replied to the list earlier.)

On 17 February 2010 21:51, Onno Kortmann <address@hidden> wrote:
> 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?

Nope, just commons sense. (Performance was not the motivation, I need
that change anyway.)

> 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.

Oh, great. I was not aware the change was already done.

There are a lot of instructions (DecodedInstruction children) and a
lot of access code. I thought it would be pity to loose the ability to
mechanically (by grep) find the places where ALU regs, IO regs or data
SRAM is accessed. Also it allows checking that IO number properly has
or lacks the 0x20 offset.
I have no other opinion on that matter.

> 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.

My two cents: The AvrFactory in Onno's repo uses singleton, factory
patterns, running a code before main() to do a work which could be
done by one switch(). Yes, the complex approach allows adding a new
device class just by adding a file. However:
* this happens just few times a year and
* the place which has to be altered can be found by doing a grep of an
existing device class and
* obscures the string-to-construction thing

I am fine with the rest. (I am smaller fan of design patterns.)

> 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 agree (except I do not know about the git).
Plus some of the patches were committed somewhere (e.g. Onno's repo)
and yet it is not mentioned in the patch tracker. This also makes
project look dead. (Oh, I should have fixed that.)

> 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!

I think that Git's advantages would have no effect in centralized
development (if this is what you propose). In that case Subversion
would be sufficient and easier to learn/use.

(Since I am working on cathedral-style assignment in private repo
anyway I would benefit from Git. However I am afraid that Git's
advantages would be offset by its user-unfriendliness. I have heard
ugly things. And I have a mental block on learning/doing things which
are better suited for computer - e.g. insisting on whitespace conflict
while user's do not care for whitespace. You might consider me
'disabled'.)

--
Petr Hluzin