On Nov 28, 2006, at 8:33 AM, Kay-Uwe Kasemir wrote:
Hi:
Do I understand correctly that the most likely impact for EPICS
might be this type of code:
struct xyz_regs
{
Word control;
Word status;
...
}
void xyz_operate(char *vme_base)
{
struct xyz_regs *xyz = (struct xyz_regs *) vme_base;
xyz->control = 0x1234;
if (xyz->status & 0x8000)
....
}
The mapping of C structures to hardware registers?
In that case, the compiler optimization of aliased pointers
isn't the only problem. There's also the structure padding,
memory alignment, and byte order that causes portability issues.
Isn't that best handled by performing 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
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793
- Replies:
- Re: C strict aliasing rules Kay-Uwe Kasemir
- 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
- Navigate by Date:
- Prev:
Re: C strict aliasing rules Kay-Uwe Kasemir
- Next:
Re: C strict aliasing rules Kay-Uwe Kasemir
- 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 Kay-Uwe Kasemir
- Next:
Re: C strict aliasing rules Kay-Uwe Kasemir
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|