From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8343 invoked by alias); 4 Dec 2001 13:44:20 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8302 invoked from network); 4 Dec 2001 13:44:14 -0000 Received: from unknown (HELO mail00.oculustech.com) (64.221.47.99) by sources.redhat.com with SMTP; 4 Dec 2001 13:44:14 -0000 Received: from oculustech.com (dsl-64-192-85-73.telocity.com [64.192.85.73]) by mail00.oculustech.com (Postfix) with ESMTP id 04C688875 for ; Tue, 4 Dec 2001 08:43:42 -0500 (EST) Message-ID: <3C0CD32D.A118C5A0@oculustech.com> Date: Tue, 04 Dec 2001 05:44:00 -0000 From: Timothy Wall Reply-To: twall@oculustech.com Organization: Oculus Technologies X-Mailer: Mozilla 4.74 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: packing/unpacking 4-octet longs Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00016.txt.bz2 I'm working on a DSP port (yes, I'm the one tossing the OCTETS_PER_BYTE strangeness about) and TI has introduced yet another Really Strange Thing. Longs on this chip are packed little-endian. No wait, they're packed big-endian. No-wait, it's both! Basically, words are packed little-endian w/r/t octets, but the two words are big-endian, e.g. 0xaabbccdd is stored as 0xbb 0xaa 0xdd 0xcc. This I can account for in the long/float/double packing/unpacking routines (though I'm not sure how I'm going to make a clean patch yet...). The problem is that the word order switches if the value is accessed at an odd address (apparently this made sense to the hardware designers). The MS word of a long is always the first one accessed (they must have forgotten that the chip was little-endian). Any ideas of how to make this happen? I remember doing a fix for something similar way back, but looking at the code now, by the time the data is packed/unpacked, the target address is long gone. I doubt I can reliably do swapping every time I access a 4-octet block of target data. T.