EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Compiler switches on RISC byte alignment
From: "J. Frederick Bartlett" <[email protected]>
To: Kay-Uwe Kasemir <[email protected]>
Cc: EPICS Tech Talk <[email protected]>
Date: Thu, 02 Sep 2004 15:13:49 -0500
  If we had stayed with the Pascal/Modula/Oberon family, this particular
problem would be solved by the pack and unpack built-in functions. In this
era of C++ dominance I continue to pine for the clarity of Niklaus Wirth's
syntax design.

											Fritz

> -----Original Message-----
> From: Kay-Uwe Kasemir [mailto:[email protected]]
> Sent: Thursday, September 02, 2004 2:28 PM
> To: Lawrence T. Hoff
> Cc: Fairley, Diane; EPICS Tech Talk
> Subject: Re: Compiler switches on RISC byte alignment
>
>
> Hi:
>
> I'm surprised Jeff Hill hasn't jumped onto this thread.
> He and I had talked about similar issues before.
> Maybe he's getting some work done and ignoring tech-talk.
>
> Anyway, the thing about using packed structures
> in order to access memory mapped I/O or
> raw network packages is that you often run
> into compiler-specific "pack" instructions.
> Larry's copy works around the alignment,
> next you'd run into byte order issues when
> you change the CPU type.
>
> The most portable way of coding might be
> to always use byte pointers and assemble/disassemble
> the data yourself. So instead of
> .....
> typedef struct __attribute__ ((packed)){
>       unsigned char  uCh;
>       short          sInt;
> .....
> you use
> .....
>    volatile char *buf = <some address>;
>    unsigned char uCh = *(buf++);
>    unsigned short low = *(buf++);
>    unsigned short high = *(buf++);
>    short sInt = (high << 8) | low;
> .....
>
> You can somewhat beautify this by defining routines
> unpack_short(), ...
>
> -Kay
>
> On Sep 2, 2004, at 14:56, Lawrence T. Hoff wrote:
> >    As far as I know, that is a characteristic of the SPARC processor,
> > and cannot be
> > influenced by compiler directives. You *can* use byte-oriented
> > instructions on
> > data which is not on "natural" boundaries. I.e. you could access
> > "lInt" as follows
> > (from a packed array):
> >
> > unsigned long int temp;
> > memcpy(&temp, &testdata.lInt, sizeof(temp));
> >
> > printf("testdata.lInt = %lu", temp)
> >
> > HTH -- Larry
> >
> >>
> >> does not print the right value.  A pointer to an unaligned structure
> >> member results in a segment violation.
> >>
> >
> >
>
>


References:
Re: Compiler switches on RISC byte alignment Kay-Uwe Kasemir

Navigate by Date:
Prev: RE: Compiler switches on RISC byte alignment Fairley, Diane
Next: Re: LabVIEW/EPICS Brand Dr. Holger
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Compiler switches on RISC byte alignment Kay-Uwe Kasemir
Next: Re: Compiler switches on RISC byte alignment Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·