Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: C strict aliasing rules
From: Kay-Uwe Kasemir <kasemirk@ornl.gov>
To: Core talk list <core-talk@aps.anl.gov>
Date: Tue, 28 Nov 2006 10:14:36 -0500
On Nov 28, 2006, at 09:58 , Eric Norum wrote:
On Nov 28, 2006, at 8:33 AM, Kay-Uwe Kasemir wrote:
... perform...register access
via routines like the vxWorks sysInByte(), sysInWord(), sysInLong (), sysPciInLong(), ... ?

I'm more concerned about:
	all the casts between dbCommon and a particular record type
casts between generic I/O buffer space and some particular data representation
I/O buffer space is very similar to register access. Something like
   Byte low = getByte(buffer, 0);
   Byte high = getByte(buffer, 1);
   Word value = ((Word)high << 8) | low;
is cleaner than casting pointers and using #ifdef BIG_ENDIAN.
Mapping structures directly to memory might at one time have been much faster,
but also resulted in weird crashes on each new architecture,
and ended with all the 'RISC_pad..' entries in db_access.h.

I agree that the dbCommon <-> xyzRecord casts are a big problem.
I guess the politically correct solution would be to
change all that to C++ or objective C, where the language
actually supports inheritance. But that's unrealistic.
So in the end, the only practical solution is really compiler
options, and maybe a unit test like the code you already emailed
for asserting that the compiler doesn't optimize EPICS to NOPs.

-Kay


References:
C strict aliasing rules Eric Norum
Re: C strict aliasing rules Benjamin Franksen
Re: C strict aliasing rules Eric Norum
Re: C strict aliasing rules Benjamin Franksen
Re: C strict aliasing rules Kay-Uwe Kasemir
Re: C strict aliasing rules Eric Norum

Navigate by Date:
Prev: Re: C strict aliasing rules Eric Norum
Next: Re: C strict aliasing rules Marty Kraimer
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: C strict aliasing rules Eric Norum
Next: Re: C strict aliasing rules Marty Kraimer
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·