On 2/16/07, Theodore H. Smith <[EMAIL PROTECTED]> wrote:
> From: "Peter K. Stys" <[EMAIL PROTECTED]>
> Date: Fri, 16 Feb 2007 16:24:01 -0500
>
> On 2/16/07, Frank Condello <[EMAIL PROTECTED]> wrote:
>> On 16-Feb-07, at 3:16 PM, Peter K. Stys wrote:
>>
>
>>
>> Now, I would still swap the whole block in this situation (or at
>> least the parts that need it) but do it using Ptr.Byte not
>> Memoryblock.ByteValue and you'll see a massive gain. Honestly though,
>> for large blocks like you're describing I'd do this sort of thing in
>> a plugin, which will be faster still. Once your block is swapped for
>> the current platform you can use fast Ptr access all the time without
>> worrying about endianess. You still need to pick an endianess and
>> stick to it for the file format however.
>
> but if I pick a fixed endianness, the huge memblocks will always need
> to be swapped on one of the platforms when the file is read.
That's why we are in this mess today. You do something wrong, and
then it gets embedded, and grows. Eventually everyone needs to do
everything forwards and backwards, despite that doing it forwards is
simpler and easier for everyone.
I'll bet initially it was just more convenient for Intel to do their
bytes backwards, due to some implementation quirk. By the time they
had their first release, it was too late to change despite that it
was no longer more convienient.
Anyhow that's just history.
> If the
> endianness matches the current platform, then the swap will only be
> required if the file is opened on the other platform (a far less
> frequent event).
Your logic is good, it will save the user time to have the file in
the format native to him. But then YOU must store a value in your
file to state which endianness the file is! Something like 01 for BE,
and 10 for LE.
> This could break many plugin operations that perform direct byte-wise
> access of pointers.
Good catch.
Thanks to all of you for the input. I decided to:
1) save the endianness of the memblock written to disk with the file
2) byteswap at read time only if the file's byte order differs from
the current platform's, using CFSwapInt16() [thx for the CoreEndian
tip; there is a rich OS X API to handle such byte ordering issues].
Whether this approach actually works will have to wait 'til Monday
when I have acces to both an Intel and PPC Mac at work to test.
P.
--
-------------------------------------------------------------------------------
Peter K. Stys, MD
Professor of Medicine(Neurology), Senior Scientist
Ottawa Health Research Institute, Div. of Neuroscience
Ottawa Hospital / University of Ottawa
Ontario, CANADA
tel: (613)761-5444
fax: (613)761-5330
http://www.ohri.ca/profiles/stys.asp
-------------------------------------------------------------------------------
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
