Experimental Physics and Industrial Control System

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.

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  <2006>  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: Re: C strict aliasing rules Eric Norum

Next: Re: C strict aliasing rules Marty Kraimer

Index: 2002  2003  2004  2005  <2006>  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024