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
<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
|