aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/ppc/dsputil_ppc.c
diff options
context:
space:
mode:
authorDiego Biurrun <diego@biurrun.de>2014-01-15 11:24:43 +0100
committerDiego Biurrun <diego@biurrun.de>2014-03-20 05:03:22 -0700
commit82ee14d2cedd7867920529b408ed6c7ec2f13ff1 (patch)
tree48e81cf27dba8df3f99daacd5ae2fc315193c2c4 /libavcodec/ppc/dsputil_ppc.c
parentcce791b17becc99f47e097adb93f4b4bbd382e7e (diff)
downloadffmpeg-82ee14d2cedd7867920529b408ed6c7ec2f13ff1.tar.gz
ppc: dsputil: comment formatting and wording/grammar improvements
Diffstat (limited to 'libavcodec/ppc/dsputil_ppc.c')
-rw-r--r--libavcodec/ppc/dsputil_ppc.c60
1 files changed, 29 insertions, 31 deletions
diff --git a/libavcodec/ppc/dsputil_ppc.c b/libavcodec/ppc/dsputil_ppc.c
index 8600abb19a..76b53ca7db 100644
--- a/libavcodec/ppc/dsputil_ppc.c
+++ b/libavcodec/ppc/dsputil_ppc.c
@@ -32,24 +32,23 @@
/* ***** WARNING ***** WARNING ***** WARNING ***** */
/*
-clear_blocks_dcbz32_ppc will not work properly on PowerPC processors with a
-cache line size not equal to 32 bytes.
-Fortunately all processor used by Apple up to at least the 7450 (aka second
-generation G4) use 32 bytes cache line.
-This is due to the use of the 'dcbz' instruction. It simply clear to zero a
-single cache line, so you need to know the cache line size to use it !
-It's absurd, but it's fast...
-
-update 24/06/2003 : Apple released yesterday the G5, with a PPC970. cache line
-size: 128 bytes. Oups.
-The semantic of dcbz was changed, it always clear 32 bytes. so the function
-below will work, but will be slow. So I fixed check_dcbz_effect to use dcbzl,
-which is defined to clear a cache line (as dcbz before). So we still can
-distinguish, and use dcbz (32 bytes) or dcbzl (one cache line) as required.
-
-see <http://developer.apple.com/technotes/tn/tn2087.html>
-and <http://developer.apple.com/technotes/tn/tn2086.html>
-*/
+ * clear_blocks_dcbz32_ppc will not work properly on PowerPC processors with
+ * a cache line size not equal to 32 bytes. Fortunately all processors used
+ * by Apple up to at least the 7450 (AKA second generation G4) use 32-byte
+ * cache lines. This is due to the use of the 'dcbz' instruction. It simply
+ * clears a single cache line to zero, so you need to know the cache line
+ * size to use it! It's absurd, but it's fast...
+ *
+ * update 24/06/2003: Apple released the G5 yesterday, with a PPC970.
+ * cache line size: 128 bytes. Oups.
+ * The semantics of dcbz was changed, it always clears 32 bytes. So the function
+ * below will work, but will be slow. So I fixed check_dcbz_effect to use dcbzl,
+ * which is defined to clear a cache line (as dcbz before). So we can still
+ * distinguish, and use dcbz (32 bytes) or dcbzl (one cache line) as required.
+ *
+ * see <http://developer.apple.com/technotes/tn/tn2087.html>
+ * and <http://developer.apple.com/technotes/tn/tn2086.html>
+ */
static void clear_blocks_dcbz32_ppc(int16_t *blocks)
{
register int misal = ((unsigned long)blocks & 0x00000010);
@@ -73,17 +72,17 @@ static void clear_blocks_dcbz32_ppc(int16_t *blocks)
}
}
-/* same as above, when dcbzl clear a whole 128B cache line
- i.e. the PPC970 aka G5 */
+/* Same as above, when dcbzl clears a whole 128 bytes cache line
+ * i.e. the PPC970 AKA G5. */
#if HAVE_DCBZL
static void clear_blocks_dcbz128_ppc(int16_t *blocks)
{
register int misal = ((unsigned long)blocks & 0x0000007f);
register int i = 0;
if (misal) {
- // we could probably also optimize this case,
- // but there's not much point as the machines
- // aren't available yet (2003-06-26)
+ /* We could probably also optimize this case,
+ * but there's not much point as the machines
+ * aren't available yet (2003-06-26). */
memset(blocks, 0, sizeof(int16_t)*6*64);
}
else
@@ -99,11 +98,10 @@ static void clear_blocks_dcbz128_ppc(int16_t *blocks)
#endif
#if HAVE_DCBZL
-/* check dcbz report how many bytes are set to 0 by dcbz */
-/* update 24/06/2003 : replace dcbz by dcbzl to get
- the intended effect (Apple "fixed" dcbz)
- unfortunately this cannot be used unless the assembler
- knows about dcbzl ... */
+/* Check dcbz report how many bytes are set to 0 by dcbz. */
+/* update 24/06/2003: Replace dcbz by dcbzl to get the intended effect
+ * (Apple "fixed" dcbz). Unfortunately this cannot be used unless the
+ * assembler knows about dcbzl ... */
static long check_dcbzl_effect(void)
{
register char *fakedata = av_malloc(1024);
@@ -120,8 +118,8 @@ static long check_dcbzl_effect(void)
memset(fakedata, 0xFF, 1024);
- /* below the constraint "b" seems to mean "Address base register"
- in gcc-3.3 / RS/6000 speaks. seems to avoid using r0, so.... */
+ /* Below the constraint "b" seems to mean "address base register"
+ * in gcc-3.3 / RS/6000 speaks. Seems to avoid using r0, so.... */
__asm__ volatile("dcbzl %0, %1" : : "b" (fakedata_middle), "r" (zero));
for (i = 0; i < 1024 ; i ++) {
@@ -144,7 +142,7 @@ av_cold void ff_dsputil_init_ppc(DSPContext *c, AVCodecContext *avctx)
{
const int high_bit_depth = avctx->bits_per_raw_sample > 8;
- // Common optimizations whether AltiVec is available or not
+ // common optimizations whether AltiVec is available or not
if (!high_bit_depth) {
switch (check_dcbzl_effect()) {
case 32: