[Ffmpeg-devel] Re: [PATCH] Machine endian bytestream functions

[Rich Felker]

On Mon, Apr 16, 2007 at 10:33:02PM +0100, M?ns Rullg?rd wrote:
> Rich Felker <dalias at aerifal.cx> writes:
> 
> > On Mon, Apr 16, 2007 at 05:39:15PM -0300, Ramiro Ribeiro Polla wrote:
> >> I didn't know what that __packed__ was doing there. But now I checked 
> >> with an arm compiler...
> >
> > I'm not familar with the discussion, but: __packed__ is not portable
> > C. It's fine for conditionally-compiled code to use it, just like the
> > inline asm, but the whole program should build on any standard C
> > compiler as long as all arch-specific optimizations are disabled. This
> > means that you cannot rely on attribute(__packed__) to do the
> > unaligned reads/writes for you; you must use byte-by-byte code in the
> > general case.
> 
> Yes, of course.  As I explained earlier, we can't check whether
> unaligned accesses work.  This means we must have a fallback to
> byte-by-byte reading.  In addition, we can implement either or both of
> gcc attribute(packed) (or equivalent for other compilers) or a manual
> list.  Letting the compiler choose is probably to be preferred since
> it should be able to generate the most efficient code.  Reading four
> bytes is not necessarily the fastest.  For the case that the compiler
> doesn't have a notion of unaligned accesses we can either use a list
> of architectures, or we can assume this is rare enough that we just
> fall back to byte-reading.

I'm the rabid portability police here, and I'm plenty happy if you
just fall back to byte reading for non-gcc compilers. I just demand
that the code works, not that it work fast. Then we maintain the
opening for use of non-gcc compilers, and people wanting to experiment
with such things can add optimizations later if desired.

On the other hand if it's easy to leave the "unaligned access is ok"
support in place for x86, that'd be cool.

Rich