Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Inconsistent results between char/short/int

Reply
Thread Tools

Re: Inconsistent results between char/short/int

 
 
Eric Sosman
Guest
Posts: n/a
 
      09-24-2011
On 9/23/2011 9:46 AM, Guillaume Dargaud wrote:
> Hello all,
> I know it's frowned upon to post system-specific code here, but I'd like to
> know if the error is in my C code (wrong pointer manipulation), in my
> handling of Linux virtual mem or in weird CPU mem alignments (it's a PPC
> processor).
>[...]
> # ./Peek -w 0x81600001 0x10
> 81600001~48006001: 00000000 00000000 00000000 00000000 ................
> 81600011~48006011: 00000000 00000000 00000000 00000000 ................
> 81600021~48006021: 00000000 00000000 00000000 00000000 ................
> 81600031~48006031: 00000000 00000000 00000000 00000000 ................


In addition to the comments others have offered, it's quite
possible that your processor is unhappy trying to fetch four-byte
integers from odd addresses. Different processors will behave
differently in the face of improper alignment; among the behaviors
I've actually seen are

- The processor traps, and the O/S terminates the program
(often with "SIGBUS" or something like it).

- The processor traps, and low-level code simulates the
invalid operation in software, loading bytes one by one
and assembling the result for you. The program works but
takes a thousand or so times as long as if the access had
been properly aligned.

- The processor handles the load-and-assemble part without a
trap and without software intervention. The program works
but takes two to eight times as long as normal.

- The processor completely ignores the offending low-order
address bits, so when you fetch an int from 0x81600001 you
get the four bytes 0x81600000-0x81600003 instead of the
intended 0x81600001-0x81600004. Peculiar results ensue.

This list is not exhaustive of all possible outcomes; it's
just the outcomes I personally have observed. And it's meant as
a warning that your program is on uncertain ground ...

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Nobody
Guest
Posts: n/a
 
      09-24-2011
On Fri, 23 Sep 2011 20:21:31 -0400, Eric Sosman wrote:

> - The processor completely ignores the offending low-order
> address bits, so when you fetch an int from 0x81600001 you
> get the four bytes 0x81600000-0x81600003 instead of the
> intended 0x81600001-0x81600004. Peculiar results ensue.


The historical ARM behaviour is similar, but with the result rotated such
that the byte at the specified address is the least significant byte of
the result.

IOW, reads use the top 30 bits to determine the address, and the
bottom 2 bits to determine the rotation. Byte reads mask the resulting
word with 0xFF, word reads don't.

 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      09-29-2011
On Sat, 2011-09-24, Eric Sosman wrote:
> On 9/23/2011 9:46 AM, Guillaume Dargaud wrote:
>> Hello all,
>> I know it's frowned upon to post system-specific code here, but I'd like to
>> know if the error is in my C code (wrong pointer manipulation), in my
>> handling of Linux virtual mem or in weird CPU mem alignments (it's a PPC
>> processor).


Speaking as a C programmer, whatever PPC may do isn't weird. If your
code breaks on PPC, it's because it's broken from a language standpoint.

>> # ./Peek -w 0x81600001 0x10
>> 81600001~48006001: 00000000 00000000 00000000 00000000 ................
>> 81600011~48006011: 00000000 00000000 00000000 00000000 ................
>> 81600021~48006021: 00000000 00000000 00000000 00000000 ................
>> 81600031~48006031: 00000000 00000000 00000000 00000000 ................

>
> In addition to the comments others have offered, it's quite
> possible that your processor is unhappy trying to fetch four-byte
> integers from odd addresses.


> Different processors will behave
> differently in the face of improper alignment; among the behaviors
> I've actually seen are

....

> - The processor handles the load-and-assemble part without a
> trap and without software intervention. The program works
> but takes two to eight times as long as normal.


I'm pretty sure PPC belongs to the "minor slowdown" category. I write
PPC code for a living, and treat casts which may cause misalignment as
minor bugs, worth fixing if I'm rewriting that part anyway for other
reasons.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Inconsistent results from int(floatNumber) gershar Python 5 10-26-2010 01:07 PM
Inconsistent results uploading stereo to YouTube Doc Computer Support 1 04-23-2008 11:20 PM
Inconsistent Program Results Francine.Neary@googlemail.com C Programming 20 03-18-2007 11:39 PM
Help: Inconsistent results of org.w3c.dom-based code evoked from different programs Bryan Java 2 09-23-2004 08:38 AM
Same code, inconsistent results -- Please Help! Neo Geshel ASP .Net 2 11-03-2003 09:41 PM



Advertisments