Messages in this thread | | | Date | Sun, 06 Jun 1999 14:42:20 -0400 | From | Jeff Garzik <> | Subject | Re: RFC: Devices, buses and hotplug |
| |
"David S. Miller" wrote: > > Date: Sun, 06 Jun 1999 13:53:51 -0400 > From: Jeff Garzik <jgarzik@pobox.com> > > This is also very valuable. The newer S3 cards (and others as well) > fully support big endian as well as little endian, and it would be nice > to avoid the byteswapping that occurs in some current read*() > implementations, such as on PPC (and Sparc too?). > > No, it is invaluable and leads to sloppy and inconsistant coding. > > Byte swapping happens transparently on Sparc for PCI devices, the > normal read{b,w,l}() etc. interfaces are used for everything and it > just works. > > It works because we architected Sparc to map PCI areas in the proper > endianness. > > The end result is that you should not need "big endian" supporting > PCI devices, and in fact I consider such devices silly. Little endian > is the native PCI byte ordering, and any worthwhile architecture we > care about has hardware facilities to make them accessible at zero > cost (either via MMU mappings of device areas, or endianness > attributes in the load/store instructions themselves).
AFAIK PCI is endian-independent. (I think I saw that in a post from Martin Mares recently?) It is only that 99.999% of the PCI devices out there are PC-centric and little endian.
Anyway... one question. Who does the byte swapping, the host CPU or the peripheral?
If the answer is 'host CPU', then my response is I can write clean code that is faster because it takes advantage of big endian peripheral support.
It seems to me that, with the amount of video data being transferred to a hi-res video card, a lot of byte swapping is avoided by the host CPU. Is this incorrect? (I don't have a big endian machine to test my assertions)
> In general, when you start seeing a lot of "knobs" in an interface, it > starts to enter ugly territory, let's avoid ending up with a mess like > Solaris's DDI ok? :-)
Point taken ;-)
Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |