On Wed, 2014-01-22 at 17:29 +0000, Peter Maydell wrote: > > > Basically if it would be on real bus, get byte value > > that corresponds to phys_addr + 0 address place > > it into data[0], get byte value that corresponds to > > phys_addr + 1 address place it into data[1], etc. > > This just isn't how real buses work. Actually it can be :-) > There is no > "address + 1, address + 2". There is a single address > for the memory transaction and a set of data on > data lines and some separate size information. > How the device at the far end of the bus chooses > to respond to 32 bit accesses to address X versus > 8 bit accesses to addresses X through X+3 is entirely > its own business and unrelated to the CPU. However the bus has a definition of what byte lane is the lowest in address order. Byte order invariance is an important function of all busses. I think that trying to treat it any differently than an address ordered series of bytes is going to turn into a complete and inextricable mess. > (It would > be perfectly possible to have a device which when > you read from address X as 32 bits returned 0x12345678, > when you read from address X as 16 bits returned > 0x9abc, returned 0x42 for an 8 bit read from X+1, > and so on. Having byte reads from X..X+3 return > values corresponding to parts of the 32 bit access > is purely a convention.) Right, it's possible. It's also stupid and not how most modern devices and busses work. Besides there is no reason why that can't be implemented with Victor proposal anyway. Ben. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
