[FFmpeg-devel] [PATCH] Parsing ALS object type in MPEG-4

[Reimar Döffinger]

On Thu, Aug 20, 2009 at 03:48:33AM -0400, Ronald S. Bultje wrote:
> Hi Reimar,
> 
> On Thu, Aug 20, 2009 at 2:22 AM, Reimar
> D?ffinger<Reimar.Doeffinger at gmx.de> wrote:
> > On Wed, Aug 19, 2009 at 08:18:19PM -0400, Ronald S. Bultje wrote:
> >> On Wed, Aug 19, 2009 at 8:10 PM, Thilo
> >> Borgmann<thilo.borgmann at googlemail.com> wrote:
> >> >>> + ? ?if (get_bits_long(gb, 32) != 0x414C5300)
> >> >> MKBETAG('A','L','S','\0')
> >> > Done.
> >> [..]
> >> > + ? ? ? ?if (show_bits_long(&gb, 24) != 0x414C53) {
> >>
> >> same here (MKBETAG(0, 'A', 'L', 'S'))?
> >
> > How about AV_RB24("ALS") and AV_RL24("ALS") ?
> 
> (Completely irrelevant performance-wise, but ...) do they actually
> expand to the same asm (with a reasonably modern gcc -O3-style
> compiler)? Or is the string part of the generated asm for the second
> case / is the first therefore in fact more efficient?
> 
> (I've always preferred the MK*TAG() over string-parsing with the
> assumption that it'd be more efficient...)

Code:
return "123"[0] | ("123"[1] << 8) | ("123"[2] << 16);

Using
gcc (Gentoo 4.3.4 p1.0, pie-10.1.5) 4.3.4
on AMD64
At -O0:
  40054a:       b8 31 00 00 00          mov    $0x31,%eax
  40054f:       0f be d0                movsbl %al,%edx
  400552:       b8 32 00 00 00          mov    $0x32,%eax
  400557:       0f be c0                movsbl %al,%eax
  40055a:       c1 e0 08                shl    $0x8,%eax
  40055d:       09 c2                   or     %eax,%edx
  40055f:       b8 33 00 00 00          mov    $0x33,%eax
  400564:       0f be c0                movsbl %al,%eax
  400567:       c1 e0 10                shl    $0x10,%eax
  40056a:       09 d0                   or     %edx,%eax

At -O1:
  40054a:       b8 31 32 33 00          mov    $0x333231,%eax
  40054f:       48 83 c4 08             add    $0x8,%rsp
  400553:       c3                      retq   

Conclusion: even at -O0 the string is never stored as string.
At -O1, the whole thing compiles to a single int.
Which means that contrary to my concerns, it should even be possible to
use that construct in a switch...case without real issues.
The MK*TAG is basically the same, just with the array access less, it
should give exactly the same asm (with that gcc version).