Am 06.11.2010 um 13:05 schrieb Mark Cave-Ayland:
Andreas Färber wrote:
I was planning to do the same thing for ppc64, please go ahead. The alternative would've been to create separate range structs - cleaner API-wise, but then the range logic would need to be duplicated, which I consider a big con. ;)
Yeah, that's what I was thinking. I know that the old SPARC64 code used to reference addresses in the translation_t struct linked list directly in the MMU miss handlers, but that section has now been replaced with C code. Are there any similar gotchas on PPC?
Not that I'm aware of. Alex?
We may need to tidy arch/ppc/qemu/ofmem.c though wrt ucell. I noticed there's a private get_ram/rom/sth_size() function defined in the header but it's only used further down in the same file, so I'll probably change the type to phys_addr_t and make it static.
I'm also thinking it would be nice to have a couple of functions for each arch such as POP_PHYS() and PUSH_PHYS() which will PUSH/POP stack items into phys_addr_t and vice-versa. I think this will also allow a nice tidy up of the areas where these conversions take place, e.g. the MMU handlers.
Sounds fine to me, and making them inline functions rather than macros will probably make Blue happy, too. :)
Looks like I'm busy for the rest of the day, so will try and have a stab at this tomorrow.
Great. I've been postponing this to not open another can of worms on ppc64.
Andreas