lkml.org 
[lkml]   [1999]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Linux/IA-64 byte order
Date
In article <XFMail.990310124208.jeremy@goop.org>,
Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>On 10-Mar-99 Zygo Blaxell wrote:
>> The one caveat is that you can't do a memcpy() from BE to LE and
>> vice-versa. If you do, then you have BE data on an LE page and the magic
>> translation doesn't work properly any more.
>
>It's worse than that. A simple byte-at-a-time memcpy will work OK in some
>predictable way, but optimised memcpy implementation will use a mixture of
>byte, word and even cache line memory reads/writes depending on the CPU and
>memory architecture. This will completely confuse the hardware byte-swizzler
>and you end up with a complete mess.

Actually I had assumed that the optimized memcpy would bypass the
byte-swizzler. If it _doesn't_ bypass the byte swizzler, then Dave
Miller's example actually works if all the data is aligned to boundaries
the same size as the unit copied through the byte swizzler, but then nothing
else does.

>The solution, I suppose, is to have memory instructions with always use a fixed
>endianness, regardless of what the page endianness properties are, but "clean"
>and "elegant" are long gone.

True.

--
Zygo Blaxell, Linux Engineer, Corel Corporation, zygob@corel.ca (work),
zblaxell@furryterror.org (play). It's my opinion, I tell you! Mine! All MINE!
Linux mokona 2.2.2 #1 Mar 1 03:05 EST 1999 i586 up 1 day, 15:29
Linux washu 2.2.3 #1 Mar 8 14:53 EST 1999 i686 up 2 days, 1:35

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.124 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site