Hi Ben, > Note about the Amiga stuff: it's a bad idea :-) Every attempt > at "magically" fixing endian in HW is a recipe for tears and > disasters.
I fully agree. It's one of the problem I encountered with some similiar approach on some other big-endian Freescale CPU. It is implemented as a hard-wired 'endian-swap feature' and it simply makes everything much more complicated for code intended to run on LE and BE CPU by virtually adding some additional special case. > Approximately ... always. The only cases that I know that > have a remote chance of being useful are specifically > programmable swappers on a given device or per-page endian > configuration in the processor (like BooKE). Also agree. There might be use-cases, where hardware-supported endian-swapping might be useful. But it must be an optional feature. It's already some PITA to develope and maintain drivers running on LE/BE CPUs and to properly access word and longword PCI registers endian-transparent. Byte streams should never be affected by endianess anyway. Automatic endian-swapping might speed up some register accesses or e.g. framebuffer accesses (reverse pixel endianess), but in general it adds more problems than it's worth. The framebuffer use-case is currently the only one, where such a hardware-swapper could be really useful. But still the drivers would have to know about this feature, it would require query/set macros/fcts for endian translation modes in the kernel, ... - in short it causes lots of extra overhead. And for framebuffers the need for such hard-ware swappers can be eleminated by using the right framebuffer mode. I fear, that such hard-wired 'magic' swapping is the source and reason for some of my current problems. Carsten _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev