New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
#!/bin/sh
|
|
|
|
self=$0
|
|
|
|
|
|
|
|
usage() {
|
|
|
|
cat <<EOF >&2
|
|
|
|
Usage: $self [options] FILE
|
|
|
|
|
|
|
|
Reads the Run Time CPU Detections definitions from FILE and generates a
|
|
|
|
C header file on stdout.
|
|
|
|
|
|
|
|
Options:
|
|
|
|
--arch=ARCH Architecture to generate defs for (required)
|
|
|
|
--disable-EXT Disable support for EXT extensions
|
|
|
|
--require-EXT Require support for EXT extensions
|
|
|
|
--sym=SYMBOL Unique symbol to use for RTCD initialization function
|
|
|
|
--config=FILE File with CONFIG_FOO=yes lines to parse
|
|
|
|
EOF
|
|
|
|
exit 1
|
|
|
|
}
|
|
|
|
|
|
|
|
die() {
|
|
|
|
echo "$@" >&2
|
|
|
|
exit 1
|
|
|
|
}
|
|
|
|
|
|
|
|
die_argument_required() {
|
|
|
|
die "Option $opt requires argument"
|
|
|
|
}
|
|
|
|
|
|
|
|
for opt; do
|
|
|
|
optval="${opt#*=}"
|
|
|
|
case "$opt" in
|
|
|
|
--arch) die_argument_required;;
|
|
|
|
--arch=*) arch=${optval};;
|
|
|
|
--disable-*) eval "disable_${opt#--disable-}=true";;
|
|
|
|
--require-*) REQUIRES="${REQUIRES}${opt#--require-} ";;
|
|
|
|
--sym) die_argument_required;;
|
|
|
|
--sym=*) symbol=${optval};;
|
|
|
|
--config=*) config_file=${optval};;
|
|
|
|
-h|--help)
|
|
|
|
usage
|
|
|
|
;;
|
|
|
|
-*)
|
|
|
|
die "Unrecognized option: ${opt%%=*}"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
defs_file="$defs_file $opt"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done
|
|
|
|
for f in $defs_file; do [ -f "$f" ] || usage; done
|
|
|
|
[ -n "$arch" ] || usage
|
|
|
|
|
|
|
|
# Import the configuration
|
|
|
|
[ -f "$config_file" ] && eval $(grep CONFIG_ "$config_file")
|
|
|
|
|
|
|
|
#
|
|
|
|
# Routines for the RTCD DSL to call
|
|
|
|
#
|
|
|
|
prototype() {
|
2013-02-21 23:11:13 +04:00
|
|
|
rtyp=""
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
case "$1" in
|
|
|
|
unsigned) rtyp="$1 "; shift;;
|
|
|
|
esac
|
|
|
|
rtyp="${rtyp}$1"
|
2013-02-21 23:11:13 +04:00
|
|
|
fn="$2"
|
|
|
|
args="$3"
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
|
|
|
|
eval "${2}_rtyp='$rtyp'"
|
|
|
|
eval "${2}_args='$3'"
|
|
|
|
ALL_FUNCS="$ALL_FUNCS $fn"
|
|
|
|
specialize $fn c
|
|
|
|
}
|
|
|
|
|
|
|
|
specialize() {
|
2013-02-21 23:11:13 +04:00
|
|
|
fn="$1"
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
shift
|
|
|
|
for opt in "$@"; do
|
|
|
|
eval "${fn}_${opt}=${fn}_${opt}"
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
|
|
|
require() {
|
|
|
|
for fn in $ALL_FUNCS; do
|
|
|
|
for opt in "$@"; do
|
2013-02-21 23:11:13 +04:00
|
|
|
ofn=$(eval "echo \$${fn}_${opt}")
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
[ -z "$ofn" ] && continue
|
|
|
|
|
|
|
|
# if we already have a default, then we can disable it, as we know
|
|
|
|
# we can do better.
|
2013-02-21 23:11:13 +04:00
|
|
|
best=$(eval "echo \$${fn}_default")
|
|
|
|
best_ofn=$(eval "echo \$${best}")
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
[ -n "$best" ] && [ "$best_ofn" != "$ofn" ] && eval "${best}_link=false"
|
|
|
|
eval "${fn}_default=${fn}_${opt}"
|
|
|
|
eval "${fn}_${opt}_link=true"
|
|
|
|
done
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
|
|
|
forward_decls() {
|
|
|
|
ALL_FORWARD_DECLS="$ALL_FORWARD_DECLS $1"
|
|
|
|
}
|
|
|
|
|
|
|
|
#
|
|
|
|
# Include the user's directives
|
|
|
|
#
|
|
|
|
for f in $defs_file; do
|
|
|
|
. $f
|
|
|
|
done
|
|
|
|
|
|
|
|
#
|
|
|
|
# Process the directives according to the command line
|
|
|
|
#
|
|
|
|
process_forward_decls() {
|
|
|
|
for fn in $ALL_FORWARD_DECLS; do
|
|
|
|
eval $fn
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
|
|
|
determine_indirection() {
|
|
|
|
[ "$CONFIG_RUNTIME_CPU_DETECT" = "yes" ] || require $ALL_ARCHS
|
|
|
|
for fn in $ALL_FUNCS; do
|
2013-02-21 23:11:13 +04:00
|
|
|
n=""
|
|
|
|
rtyp="$(eval "echo \$${fn}_rtyp")"
|
|
|
|
args="$(eval "echo \"\$${fn}_args\"")"
|
|
|
|
dfn="$(eval "echo \$${fn}_default")"
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
dfn=$(eval "echo \$${dfn}")
|
|
|
|
for opt in "$@"; do
|
2013-02-21 23:11:13 +04:00
|
|
|
ofn=$(eval "echo \$${fn}_${opt}")
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
[ -z "$ofn" ] && continue
|
2013-02-21 23:11:13 +04:00
|
|
|
link=$(eval "echo \$${fn}_${opt}_link")
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
[ "$link" = "false" ] && continue
|
|
|
|
n="${n}x"
|
|
|
|
done
|
|
|
|
if [ "$n" = "x" ]; then
|
|
|
|
eval "${fn}_indirect=false"
|
|
|
|
else
|
|
|
|
eval "${fn}_indirect=true"
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
|
|
|
declare_function_pointers() {
|
|
|
|
for fn in $ALL_FUNCS; do
|
2013-02-21 23:11:13 +04:00
|
|
|
rtyp="$(eval "echo \$${fn}_rtyp")"
|
|
|
|
args="$(eval "echo \"\$${fn}_args\"")"
|
|
|
|
dfn="$(eval "echo \$${fn}_default")"
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
dfn=$(eval "echo \$${dfn}")
|
|
|
|
for opt in "$@"; do
|
2013-02-21 23:11:13 +04:00
|
|
|
ofn=$(eval "echo \$${fn}_${opt}")
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
[ -z "$ofn" ] && continue
|
|
|
|
echo "$rtyp ${ofn}($args);"
|
|
|
|
done
|
|
|
|
if [ "$(eval "echo \$${fn}_indirect")" = "false" ]; then
|
|
|
|
echo "#define ${fn} ${dfn}"
|
|
|
|
else
|
|
|
|
echo "RTCD_EXTERN $rtyp (*${fn})($args);"
|
|
|
|
fi
|
|
|
|
echo
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
|
|
|
set_function_pointers() {
|
|
|
|
for fn in $ALL_FUNCS; do
|
2013-02-21 23:11:13 +04:00
|
|
|
n=""
|
|
|
|
rtyp="$(eval "echo \$${fn}_rtyp")"
|
|
|
|
args="$(eval "echo \"\$${fn}_args\"")"
|
|
|
|
dfn="$(eval "echo \$${fn}_default")"
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
dfn=$(eval "echo \$${dfn}")
|
|
|
|
if $(eval "echo \$${fn}_indirect"); then
|
|
|
|
echo " $fn = $dfn;"
|
|
|
|
for opt in "$@"; do
|
2013-02-21 23:11:13 +04:00
|
|
|
ofn=$(eval "echo \$${fn}_${opt}")
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
[ -z "$ofn" ] && continue
|
|
|
|
[ "$ofn" = "$dfn" ] && continue;
|
2013-02-21 23:11:13 +04:00
|
|
|
link=$(eval "echo \$${fn}_${opt}_link")
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
[ "$link" = "false" ] && continue
|
2013-02-21 23:11:13 +04:00
|
|
|
cond="$(eval "echo \$have_${opt}")"
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
echo " if (${cond}) $fn = $ofn;"
|
|
|
|
done
|
|
|
|
fi
|
|
|
|
echo
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
|
|
|
filter() {
|
2013-02-21 23:11:13 +04:00
|
|
|
filtered=""
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
for opt in "$@"; do
|
|
|
|
[ -z $(eval "echo \$disable_${opt}") ] && filtered="$filtered $opt"
|
|
|
|
done
|
|
|
|
echo $filtered
|
|
|
|
}
|
|
|
|
|
|
|
|
#
|
|
|
|
# Helper functions for generating the arch specific RTCD files
|
|
|
|
#
|
|
|
|
common_top() {
|
2013-02-23 04:03:40 +04:00
|
|
|
outfile_basename=$(basename ${symbol:-rtcd})
|
|
|
|
include_guard=$(echo $outfile_basename | tr '[a-z]' '[A-Z]' | \
|
|
|
|
tr -c '[A-Z0-9]' _)H_
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
cat <<EOF
|
|
|
|
#ifndef ${include_guard}
|
|
|
|
#define ${include_guard}
|
|
|
|
|
|
|
|
#ifdef RTCD_C
|
|
|
|
#define RTCD_EXTERN
|
|
|
|
#else
|
|
|
|
#define RTCD_EXTERN extern
|
|
|
|
#endif
|
|
|
|
|
|
|
|
$(process_forward_decls)
|
|
|
|
|
|
|
|
$(declare_function_pointers c $ALL_ARCHS)
|
2012-06-16 02:40:13 +04:00
|
|
|
|
|
|
|
void ${symbol:-rtcd}(void);
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
EOF
|
|
|
|
}
|
|
|
|
|
|
|
|
common_bottom() {
|
|
|
|
cat <<EOF
|
|
|
|
#endif
|
|
|
|
EOF
|
|
|
|
}
|
|
|
|
|
|
|
|
x86() {
|
|
|
|
determine_indirection c $ALL_ARCHS
|
|
|
|
|
|
|
|
# Assign the helper variable for each enabled extension
|
|
|
|
for opt in $ALL_ARCHS; do
|
2013-02-21 23:11:13 +04:00
|
|
|
uc=$(echo $opt | tr '[a-z]' '[A-Z]')
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
eval "have_${opt}=\"flags & HAS_${uc}\""
|
|
|
|
done
|
|
|
|
|
|
|
|
cat <<EOF
|
|
|
|
$(common_top)
|
|
|
|
|
|
|
|
#ifdef RTCD_C
|
|
|
|
#include "vpx_ports/x86.h"
|
2012-06-16 02:40:13 +04:00
|
|
|
static void setup_rtcd_internal(void)
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
{
|
|
|
|
int flags = x86_simd_caps();
|
|
|
|
|
|
|
|
(void)flags;
|
|
|
|
|
|
|
|
$(set_function_pointers c $ALL_ARCHS)
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
$(common_bottom)
|
|
|
|
EOF
|
|
|
|
}
|
|
|
|
|
|
|
|
arm() {
|
|
|
|
determine_indirection c $ALL_ARCHS
|
|
|
|
|
|
|
|
# Assign the helper variable for each enabled extension
|
|
|
|
for opt in $ALL_ARCHS; do
|
2013-02-21 23:11:13 +04:00
|
|
|
uc=$(echo $opt | tr '[a-z]' '[A-Z]')
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
eval "have_${opt}=\"flags & HAS_${uc}\""
|
|
|
|
done
|
|
|
|
|
|
|
|
cat <<EOF
|
|
|
|
$(common_top)
|
|
|
|
#include "vpx_config.h"
|
|
|
|
|
|
|
|
#ifdef RTCD_C
|
|
|
|
#include "vpx_ports/arm.h"
|
2012-06-16 02:40:13 +04:00
|
|
|
static void setup_rtcd_internal(void)
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
{
|
|
|
|
int flags = arm_cpu_caps();
|
|
|
|
|
|
|
|
(void)flags;
|
|
|
|
|
|
|
|
$(set_function_pointers c $ALL_ARCHS)
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
$(common_bottom)
|
|
|
|
EOF
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-04-11 20:53:15 +04:00
|
|
|
mips() {
|
|
|
|
determine_indirection c $ALL_ARCHS
|
|
|
|
cat <<EOF
|
|
|
|
$(common_top)
|
|
|
|
#include "vpx_config.h"
|
|
|
|
|
|
|
|
#ifdef RTCD_C
|
2012-07-11 19:56:53 +04:00
|
|
|
static void setup_rtcd_internal(void)
|
2012-04-11 20:53:15 +04:00
|
|
|
{
|
2012-07-11 19:56:53 +04:00
|
|
|
$(set_function_pointers c $ALL_ARCHS)
|
2012-04-11 20:53:15 +04:00
|
|
|
#if HAVE_DSPR2
|
2013-09-29 21:27:11 +04:00
|
|
|
#if CONFIG_VP8
|
2012-04-11 20:53:15 +04:00
|
|
|
void dsputil_static_init();
|
|
|
|
dsputil_static_init();
|
|
|
|
#endif
|
2013-09-13 13:48:32 +04:00
|
|
|
#if CONFIG_VP9
|
|
|
|
void vp9_dsputil_static_init();
|
|
|
|
vp9_dsputil_static_init();
|
|
|
|
#endif
|
2013-09-29 21:27:11 +04:00
|
|
|
#endif
|
2012-04-11 20:53:15 +04:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
$(common_bottom)
|
|
|
|
EOF
|
|
|
|
}
|
|
|
|
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
unoptimized() {
|
|
|
|
determine_indirection c
|
|
|
|
cat <<EOF
|
|
|
|
$(common_top)
|
|
|
|
#include "vpx_config.h"
|
|
|
|
|
|
|
|
#ifdef RTCD_C
|
2012-06-16 02:40:13 +04:00
|
|
|
static void setup_rtcd_internal(void)
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
{
|
|
|
|
$(set_function_pointers c)
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
$(common_bottom)
|
|
|
|
EOF
|
|
|
|
|
|
|
|
}
|
|
|
|
#
|
|
|
|
# Main Driver
|
|
|
|
#
|
|
|
|
require c
|
|
|
|
case $arch in
|
|
|
|
x86)
|
2013-10-29 19:48:12 +04:00
|
|
|
ALL_ARCHS=$(filter mmx sse sse2 sse3 ssse3 sse4_1 avx avx2)
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
x86
|
|
|
|
;;
|
|
|
|
x86_64)
|
2013-10-29 19:48:12 +04:00
|
|
|
ALL_ARCHS=$(filter mmx sse sse2 sse3 ssse3 sse4_1 avx avx2)
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
REQUIRES=${REQUIRES:-mmx sse sse2}
|
|
|
|
require $(filter $REQUIRES)
|
|
|
|
x86
|
|
|
|
;;
|
2012-04-11 20:53:15 +04:00
|
|
|
mips32)
|
|
|
|
ALL_ARCHS=$(filter mips32)
|
|
|
|
dspr2=$([ -f "$config_file" ] && eval echo $(grep HAVE_DSPR2 "$config_file"))
|
|
|
|
HAVE_DSPR2="${dspr2#*=}"
|
|
|
|
if [ "$HAVE_DSPR2" = "yes" ]; then
|
|
|
|
ALL_ARCHS=$(filter mips32 dspr2)
|
|
|
|
fi
|
|
|
|
mips
|
|
|
|
;;
|
New RTCD implementation
This is a proof of concept RTCD implementation to replace the current
system of nested includes, prototypes, INVOKE macros, etc. Currently
only the decoder specific functions are implemented in the new system.
Additional functions will be added in subsequent commits.
Overview:
RTCD "functions" are implemented as either a global function pointer
or a macro (when only one eligible specialization available).
Functions which have RTCD specializations are listed using a simple
DSL identifying the function's base name, its prototype, and the
architecture extensions that specializations are available for.
Advantages over the old system:
- No INVOKE macros. A call to an RTCD function looks like an ordinary
function call.
- No need to pass vtables around.
- If there is only one eligible function to call, the function is
called directly, rather than indirecting through a function pointer.
- Supports the notion of "required" extensions, so in combination with
the above, on x86_64 if the best function available is sse2 or lower
it will be called directly, since all x86_64 platforms implement
sse2.
- Elides all references to functions which will never be called, which
could reduce binary size. For example if sse2 is required and there
are both mmx and sse2 implementations of a certain function, the
code will have no link time references to the mmx code.
- Significantly easier to add a new function, just one file to edit.
Disadvantages:
- Requires global writable data (though this is not a new requirement)
- 1 new generated source file.
Change-Id: Iae6edab65315f79c168485c96872641c5aa09d55
2011-08-19 22:06:00 +04:00
|
|
|
armv5te)
|
|
|
|
ALL_ARCHS=$(filter edsp)
|
|
|
|
arm
|
|
|
|
;;
|
|
|
|
armv6)
|
|
|
|
ALL_ARCHS=$(filter edsp media)
|
|
|
|
arm
|
|
|
|
;;
|
|
|
|
armv7)
|
|
|
|
ALL_ARCHS=$(filter edsp media neon)
|
|
|
|
arm
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
unoptimized
|
|
|
|
;;
|
|
|
|
esac
|