[Ffmpeg-devel] PATCH Blackfin UNALIGNED_STORES_ARE_BAD in bitstream.h

[François Revol]

> > > IMO we should turn this the other way around:
> > > 
> > > #if !defined(ARCH_X86) && !defined(...)
> > > 
> > > Then the code will ALWAYS work, and just be suboptimal on archs 
> > > we
> > > haven't identified yet, rather than crashing on unknown archs.
> > 
> > i strongly object to this, noone would ever add any architecture 
> > besides x86
> > to it, how should anyone even know of this line?
> 
> It can be documented in a porting file or something. But I strongly
> object to having blatently nonportable code in the default build. If 
> I
> were trying to compile ffmpeg on a strange system and not a competent
> coder/debugger, I would have no idea why it crashed and probably just
> assume it was nonportable crapware rather than learning how to
> investigate and "fix" the problem.

Indeed, but ppl on BeOS will currently assume nonportable crapware 
because it will fail to build on PRI* macros... just because someone 
assumes "portable" to mean porting the OS to ffmpeg instead of the 
other way around. but that's another story.

> 1. Enable the nonportable code by default but have a
> --disable-nonportable-assumptions option to configure, or an
> ARCH_GENERIC define included in the above list that configure would
> define when the arch is unknown to inhibit all such optimizations.

Why an option a newbie wouldn't know about ?
You're just shuffling the problem around.

> 2. Just have configure print a message directing users to a porting
> document with references to this line and other similar lines when an
> unknown arch is detected.

#if !defined(..)
...
#endif
#ifdef ARCH_GENERIC
#warning "FIXME: Unknown arch, assuming strict alignment. This could be 
subobtimal!!!"
#endif

> > if it crashes and the person sends a bugrport its trivial to add 
> > the arch
> > if its just slower than what it could be nothing will happen it 
> > will always
> > stay slow
> 
> This assumes the code is maintained and the user is using the latest
> version. The problem is what happens 10 years from now if ffmpeg is

That's assuming gcc will be around in 10 years ;)

> > if configure would print a big warning like
> > WARINING: configure doesnt know your architecture and so has 
> > disabled all
> > optimizations, please try the following switches: ... and report 
> > bechmarks
> > to ffmpeg-dev so we can automate the optimization selection
> 
> Yes, this would be great.

Either this or the warning, yes.
Or both so ppl who didn't write it would find where to update stuff :)

Fran?ois.