From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6800 invoked by alias); 5 Dec 2001 16:46:57 -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 6711 invoked from network); 5 Dec 2001 16:46:30 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 5 Dec 2001 16:46:30 -0000 Received: by fw-cam.cambridge.arm.com; id QAA19434; Wed, 5 Dec 2001 16:46:29 GMT Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma018763; Wed, 5 Dec 01 16:45:40 GMT Received: from cam-mail2.cambridge.arm.com (localhost [127.0.0.1]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id QAA12051; Wed, 5 Dec 2001 16:45:40 GMT Received: from sun18.cambridge.arm.com (sun18.cambridge.arm.com [172.16.2.18]) by cam-mail2.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id QAA06737; Wed, 5 Dec 2001 16:45:39 GMT Message-Id: <200112051645.QAA06737@cam-mail2.cambridge.arm.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Andrew Cagney cc: twall@oculustech.com, gdb@sources.redhat.com, Richard.Earnshaw@arm.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: packing/unpacking 4-octet longs In-reply-to: Your message of "Wed, 05 Dec 2001 11:25:58 EST." <3C0E4A96.6070601@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Dec 2001 08:46:00 -0000 From: Richard Earnshaw X-SW-Source: 2001-12/txt/msg00034.txt.bz2 > > 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). > > Mutter something about hardware engineers taking short cuts :-) As opposed to software engineers making invalid assumptions about the world they operate in :-) In particular, by ignoring bits of the standards that are inconveniently difficult to deal with... > I'm > pretty sure that there is another very old wacko architecture that did > something similar to this, I'm trying to remember which. pdp11? > original m68k? PDP11, I think. It's a bit before my time, but IIRC it's because earlier PDPS (8? 9?) were 16-bit machines, so there wasn't really any concept of word-ordering beyond that: 16-bit words were little-endian, but the most significant word was always at the lowest address (or the other way around). When the pdp-11 came out, with 32-bit operations, all this caused carnage. I'm told that it was this that convinced Digital that all the world would in future be little-endian (and hence, I believe, why MIPS processors grew a little-endian mode). > This problem also shows up on hardware that implemented > big/little endian using xor bits - Arm? I'm not aware of this affecting the ARM (except in that FPA format doubles and long doubles always have the word with the exponent at the lowest address, but there's nothing in the IEEE FP specs that says this is invalid). In particular, storing a word, or multi-word, at an unaligned address does not change the order of bytes in memory, so memcpy(unaligned_address, aligned_address, sizeof(some_word)) does not require diddling with the internal order (or have I misunderstood the problem?) R.