On 5 July 2016 at 22:41, Michael Rolnik <mrol...@gmail.com> wrote: > right it accesses CPU registers but from helper context. > the flow is as follows > > 1. there is a write to [0x0000: 0x0100) region > 2. tlb_fill is called, it does the following > a. sets env->fullwr > b. calls cpu_loop_exit_restore. > c. the whole block is retranslated and instead of st it generates > helper_fullwr for each store within this TB. > 3. helper_fullwr calls cpu_physical_memory_write > 4. sample_io_write is called and register is changed since the whole thing > is done from within a helper
Thanks for the data sheet links. Looking at them, the access to register contents via load/store instructions definitely seems to be part of the CPU itself, not a device or something at board level. So I think it should be handled by code that's suitably named (ie not "sample") and in the right place in our source tree. We have two models for this kind of thing: where the CPU has devices that are kind of built in, but still clearly separate (like timer devices some of the ARM CPUs have), we've done this by having device models for them in hw/timer etc, with a "put the devices in the right places" container object in hw/cpu. The other model, which I think is a better fit for these AVR cores, is how target-i386 handles its SMM memory. Basically in the CPU's realize function you can set up the CPU's address space to be a container which has within it (a) the magic MemoryRegion which handles the accesses to cpu registers (b) the "system address space", ie the outside world I think this will work best because it keeps the access to the cpu env and its register state within the target-avr/ code, and because the access functions for handling accesses in this low address space are so simple, and so tightly coupled to the special handling of fullwr that you describe above. The x86 code is in x86_cpu_realizefn(). (You don't need to postpone creating the second memory region until machine-done the way that code does, though.) thanks -- PMM
