Around 50% faster.
decode:       374139 -> 248852 decicycles
syntax check: 236955 -> 123854 decicycles

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Also encodes error or end marker into table.
About 20% faster.
decode:       466491 -> 374139 decicycles
syntax check: 236955 -> 161182 decicycles

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

As the test is run during fate and the benchmark is useless for fate
this very slightly speeds up fate. Its also consistent with the other
tests.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This makes the code 2-3 times as fast

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Move handling of last byte outside of innermost loop.

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The tool is useful for testing the internal arithmetic evaluation engine
(indeed I plan to use it in FATE), and provides a handy calculator when
you can't rely on bc ;-).

They allow to implement the if/then/else logic, which cannot be
implemented otherwise.

For example the expression:
A*B + not(A)*C

always evaluates to NaN if B is NaN, even in the case where A is 0.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Add it to doc/APIchanges and update and correct other entries.

Signed-off-by: Janne Grunau <janne-libav@jannau.net>

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

This only happens for a "back" value of 0 which is invalid anyway,
but lcldec does not properly validate input.
Also extend the documentation to specify valid values.

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Prior to this a X bytes write could be seen as less than X bytes being
available if the check was done at an unfortunate moment.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

It should be used to mark codepath that can be reached only through
programming error.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Mans Rullgard <mans@mansr.com>

Firstly, this test never worked as intended, always reporting
success.  Secondly, bswap is available from 486 onward and can
thus be assumed present.

Signed-off-by: Mans Rullgard <mans@mansr.com>

With these changes, gcc 4.5 and later recognise it as a bswap
and use the proper instructions on ARM and x86.  On x86, the
16-bit bswap is recognised from gcc 4.1.

Signed-off-by: Mans Rullgard <mans@mansr.com>

The existing functions defined in intfloat_readwrite.[ch] are
both slow and incorrect (infinities are not handled).

This introduces a new header with fast, inline conversion
functions using direct union punning assuming an IEEE-754
system, an assumption already made throughout the code.

The one use of Intel/Motorola extended 80-bit format is
replaced by simpler code sufficient under the present
constraints (positive normal values).

The old functions are marked deprecated and retained for
compatibility.

Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Solaris Studio (suncc) has difficulty with filling in
members of a union. Instead, let's retrieve and store the
cpuid() results separately. This is still a compiler bug,
however this fix does not cause a regression on other platforms.

Signed-off-by: Janne Grunau <janne-libav@jannau.net>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

For some of the code e.g. doing timing measurements there is no
real point in running regression testing on it, thus it should
not be counted against coverage.

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>