From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-42799-listarch-binutils=sources.redhat.com@sources.redhat.com>
Received: (qmail 11609 invoked by alias); 14 Sep 2005 19:37:36 -0000
Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:binutils-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/binutils/>
List-Post: <mailto:binutils@sources.redhat.com>
List-Help: <mailto:binutils-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: binutils-owner@sources.redhat.com
Received: (qmail 11458 invoked by uid 22791); 14 Sep 2005 19:37:04 -0000
Received: from host217-40-213-68.in-addr.btopenworld.com (HELO SERRANO.CAM.ARTIMI.COM) (217.40.213.68)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 14 Sep 2005 19:37:04 +0000
Received: from mace ([192.168.1.25]) by SERRANO.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 14 Sep 2005 20:37:00 +0100
From: "Dave Korn" <dave.korn@artimi.com>
To: "'Paul Koning'" <pkoning@equallogic.com>
Cc: <dj@redhat.com>,
	<shreyas76@gmail.com>,
	<binutils@sources.redhat.com>
Subject: RE: Address assignment
Date: Wed, 14 Sep 2005 21:20:00 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <17192.30862.611030.76521@gargle.gargle.HOWL>
Message-ID: <SERRANOprhup7IpGwC6000003da@SERRANO.CAM.ARTIMI.COM>
X-SW-Source: 2005-09/txt/msg00157.txt.bz2

----Original Message----
>From: Paul Koning
>Sent: 14 September 2005 20:23

>>>>>> "Dave" == Dave Korn <dave.korn@artimi.com> writes:
> 
>  >> Why add an unneeded level of indirection?  Especially on
>  >> time-critical embedded systems?
> 
>  Dave> These days, I really have *lots* of faith in the compiler to be
>  Dave> able to optimise that away[*].  But I guess you could always
>  Dave> write
> 
>  Dave> #define my_struct (*(struct my_struct_type *)0xa0001028)
> 
>  Dave> and treat it just like an object
> 
>  Dave> my_struct.x = 3;
> 
> If you don't want accesses optimized away, you need "volatile".
> 
>    paul


  You've missed the point.  I _do_ want accesses optimised away.  Accesses
to the pointer variable; not accesses to the thing it points at.  Yes, for
most memory-mapped h/w, you would want the object to be volatile.  But you
and I are talking about things on opposite sides of the '*':

volatile my_struct_type * const my_struct_ptr = blablablaaaa;



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....