2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: C strict aliasing rules |
From: | Eric Norum <[email protected]> |
To: | Kay-Uwe Kasemir <[email protected]> |
Cc: | Core talk list <[email protected]> |
Date: | Tue, 28 Nov 2006 08:58:47 -0600 |
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 accessvia routines like the vxWorks sysInByte(), sysInWord(), sysInLong (), sysPciInLong(), ... ?
I'm more concerned about: all the casts between dbCommon and a particular record typecasts between generic I/O buffer space and some particular data representation
-- Eric Norum <[email protected]> Advanced Photon Source Argonne National Laboratory (630) 252-4793