vpx/vp8/encoder/arm/armv5te/vp8_packtokens_mbrow_armv5.asm

328 lines
11 KiB
NASM
Raw Normal View History

2010-05-18 17:58:33 +02:00
;
; Copyright (c) 2010 The WebM project authors. All Rights Reserved.
2010-05-18 17:58:33 +02:00
;
; Use of this source code is governed by a BSD-style license
; that can be found in the LICENSE file in the root of the source
; tree. An additional intellectual property rights grant can be found
; in the file PATENTS. All contributing project authors may
; be found in the AUTHORS file in the root of the source tree.
2010-05-18 17:58:33 +02:00
;
Add runtime CPU detection support for ARM. The primary goal is to allow a binary to be built which supports NEON, but can fall back to non-NEON routines, since some Android devices do not have NEON, even if they are otherwise ARMv7 (e.g., Tegra). The configure-generated flags HAVE_ARMV7, etc., are used to decide which versions of each function to build, and when CONFIG_RUNTIME_CPU_DETECT is enabled, the correct version is chosen at run time. In order for this to work, the CFLAGS must be set to something appropriate (e.g., without -mfpu=neon for ARMv7, and with appropriate -march and -mcpu for even earlier configurations), or the native C code will not be able to run. The ASFLAGS must remain set for the most advanced instruction set required at build time, since the ARM assembler will refuse to emit them otherwise. I have not attempted to make any changes to configure to do this automatically. Doing so will probably require the addition of new configure options. Many of the hooks for RTCD on ARM were already there, but a lot of the code had bit-rotted, and a good deal of the ARM-specific code is not integrated into the RTCD structs at all. I did not try to resolve the latter, merely to add the minimal amount of protection around them to allow RTCD to work. Those functions that were called based on an ifdef at the calling site were expanded to check the RTCD flags at that site, but they should be added to an RTCD struct somewhere in the future. The functions invoked with global function pointers still are, but these should be moved into an RTCD struct for thread safety (I believe every platform currently supported has atomic pointer stores, but this is not guaranteed). The encoder's boolhuff functions did not even have _c and armv7 suffixes, and the correct version was resolved at link time. The token packing functions did have appropriate suffixes, but the version was selected with a define, with no associated RTCD struct. However, for both of these, the only armv7 instruction they actually used was rbit, and this was completely superfluous, so I reworked them to avoid it. The only non-ARMv4 instruction remaining in them is clz, which is ARMv5 (not even ARMv5TE is required). Considering that there are no ARM-specific configs which are not at least ARMv5TE, I did not try to detect these at runtime, and simply enable them for ARMv5 and above. Finally, the NEON register saving code was completely non-reentrant, since it saved the registers to a global, static variable. I moved the storage for this onto the stack. A single binary built with this code was tested on an ARM11 (ARMv6) and a Cortex A8 (ARMv7 w/NEON), for both the encoder and decoder, and produced identical output, while using the correct accelerated functions on each. I did not test on any earlier processors. Change-Id: I45cbd63a614f4554c3b325c45d46c0806f009eaa
2010-10-21 00:39:11 +02:00
EXPORT |vp8cx_pack_mb_row_tokens_armv5|
2010-05-18 17:58:33 +02:00
INCLUDE asm_enc_offsets.asm
2010-05-18 17:58:33 +02:00
ARM
REQUIRE8
PRESERVE8
AREA |.text|, CODE, READONLY
; r0 VP8_COMP *cpi
; r1 vp8_writer *w
; r2 vp8_coef_encodings
; r3 vp8_extra_bits
; s0 vp8_coef_tree
Add runtime CPU detection support for ARM. The primary goal is to allow a binary to be built which supports NEON, but can fall back to non-NEON routines, since some Android devices do not have NEON, even if they are otherwise ARMv7 (e.g., Tegra). The configure-generated flags HAVE_ARMV7, etc., are used to decide which versions of each function to build, and when CONFIG_RUNTIME_CPU_DETECT is enabled, the correct version is chosen at run time. In order for this to work, the CFLAGS must be set to something appropriate (e.g., without -mfpu=neon for ARMv7, and with appropriate -march and -mcpu for even earlier configurations), or the native C code will not be able to run. The ASFLAGS must remain set for the most advanced instruction set required at build time, since the ARM assembler will refuse to emit them otherwise. I have not attempted to make any changes to configure to do this automatically. Doing so will probably require the addition of new configure options. Many of the hooks for RTCD on ARM were already there, but a lot of the code had bit-rotted, and a good deal of the ARM-specific code is not integrated into the RTCD structs at all. I did not try to resolve the latter, merely to add the minimal amount of protection around them to allow RTCD to work. Those functions that were called based on an ifdef at the calling site were expanded to check the RTCD flags at that site, but they should be added to an RTCD struct somewhere in the future. The functions invoked with global function pointers still are, but these should be moved into an RTCD struct for thread safety (I believe every platform currently supported has atomic pointer stores, but this is not guaranteed). The encoder's boolhuff functions did not even have _c and armv7 suffixes, and the correct version was resolved at link time. The token packing functions did have appropriate suffixes, but the version was selected with a define, with no associated RTCD struct. However, for both of these, the only armv7 instruction they actually used was rbit, and this was completely superfluous, so I reworked them to avoid it. The only non-ARMv4 instruction remaining in them is clz, which is ARMv5 (not even ARMv5TE is required). Considering that there are no ARM-specific configs which are not at least ARMv5TE, I did not try to detect these at runtime, and simply enable them for ARMv5 and above. Finally, the NEON register saving code was completely non-reentrant, since it saved the registers to a global, static variable. I moved the storage for this onto the stack. A single binary built with this code was tested on an ARM11 (ARMv6) and a Cortex A8 (ARMv7 w/NEON), for both the encoder and decoder, and produced identical output, while using the correct accelerated functions on each. I did not test on any earlier processors. Change-Id: I45cbd63a614f4554c3b325c45d46c0806f009eaa
2010-10-21 00:39:11 +02:00
|vp8cx_pack_mb_row_tokens_armv5| PROC
2010-05-18 17:58:33 +02:00
push {r4-r11, lr}
sub sp, sp, #24
; Compute address of cpi->common.mb_rows
ldr r4, _VP8_COMP_common_
ldr r6, _VP8_COMMON_MBrows_
add r4, r0, r4
ldr r5, [r4, r6] ; load up mb_rows
str r2, [sp, #20] ; save vp8_coef_encodings
str r5, [sp, #12] ; save mb_rows
str r3, [sp, #8] ; save vp8_extra_bits
ldr r4, _VP8_COMP_tplist_
add r4, r0, r4
ldr r7, [r4, #0] ; dereference cpi->tp_list
mov r0, r1 ; keep same as other loops
ldr r2, [r0, #vp8_writer_lowvalue]
ldr r5, [r0, #vp8_writer_range]
ldr r3, [r0, #vp8_writer_count]
mb_row_loop
ldr r1, [r7, #tokenlist_start]
ldr r9, [r7, #tokenlist_stop]
str r9, [sp, #0] ; save stop for later comparison
str r7, [sp, #16] ; tokenlist address for next time
b check_p_lt_stop
; actuall work gets done here!
while_p_lt_stop
ldrb r6, [r1, #tokenextra_token] ; t
2010-05-18 17:58:33 +02:00
ldr r4, [sp, #20] ; vp8_coef_encodings
mov lr, #0
add r4, r4, r6, lsl #3 ; a = vp8_coef_encodings + t
ldr r9, [r1, #tokenextra_context_tree] ; pp
ldrb r7, [r1, #tokenextra_skip_eob_node]
2010-05-18 17:58:33 +02:00
ldr r6, [r4, #vp8_token_value] ; v
ldr r8, [r4, #vp8_token_len] ; n
; vp8 specific skip_eob_node
cmp r7, #0
movne lr, #2 ; i = 2
subne r8, r8, #1 ; --n
rsb r4, r8, #32 ; 32-n
ldr r10, [sp, #60] ; vp8_coef_tree
; v is kept in r12 during the token pack loop
Add runtime CPU detection support for ARM. The primary goal is to allow a binary to be built which supports NEON, but can fall back to non-NEON routines, since some Android devices do not have NEON, even if they are otherwise ARMv7 (e.g., Tegra). The configure-generated flags HAVE_ARMV7, etc., are used to decide which versions of each function to build, and when CONFIG_RUNTIME_CPU_DETECT is enabled, the correct version is chosen at run time. In order for this to work, the CFLAGS must be set to something appropriate (e.g., without -mfpu=neon for ARMv7, and with appropriate -march and -mcpu for even earlier configurations), or the native C code will not be able to run. The ASFLAGS must remain set for the most advanced instruction set required at build time, since the ARM assembler will refuse to emit them otherwise. I have not attempted to make any changes to configure to do this automatically. Doing so will probably require the addition of new configure options. Many of the hooks for RTCD on ARM were already there, but a lot of the code had bit-rotted, and a good deal of the ARM-specific code is not integrated into the RTCD structs at all. I did not try to resolve the latter, merely to add the minimal amount of protection around them to allow RTCD to work. Those functions that were called based on an ifdef at the calling site were expanded to check the RTCD flags at that site, but they should be added to an RTCD struct somewhere in the future. The functions invoked with global function pointers still are, but these should be moved into an RTCD struct for thread safety (I believe every platform currently supported has atomic pointer stores, but this is not guaranteed). The encoder's boolhuff functions did not even have _c and armv7 suffixes, and the correct version was resolved at link time. The token packing functions did have appropriate suffixes, but the version was selected with a define, with no associated RTCD struct. However, for both of these, the only armv7 instruction they actually used was rbit, and this was completely superfluous, so I reworked them to avoid it. The only non-ARMv4 instruction remaining in them is clz, which is ARMv5 (not even ARMv5TE is required). Considering that there are no ARM-specific configs which are not at least ARMv5TE, I did not try to detect these at runtime, and simply enable them for ARMv5 and above. Finally, the NEON register saving code was completely non-reentrant, since it saved the registers to a global, static variable. I moved the storage for this onto the stack. A single binary built with this code was tested on an ARM11 (ARMv6) and a Cortex A8 (ARMv7 w/NEON), for both the encoder and decoder, and produced identical output, while using the correct accelerated functions on each. I did not test on any earlier processors. Change-Id: I45cbd63a614f4554c3b325c45d46c0806f009eaa
2010-10-21 00:39:11 +02:00
lsl r12, r6, r4 ; r12 = v << 32 - n
2010-05-18 17:58:33 +02:00
; loop start
token_loop
ldrb r4, [r9, lr, asr #1] ; pp [i>>1]
sub r7, r5, #1 ; range-1
; Decisions are made based on the bit value shifted
; off of v, so set a flag here based on this.
; This value is refered to as "bb"
Add runtime CPU detection support for ARM. The primary goal is to allow a binary to be built which supports NEON, but can fall back to non-NEON routines, since some Android devices do not have NEON, even if they are otherwise ARMv7 (e.g., Tegra). The configure-generated flags HAVE_ARMV7, etc., are used to decide which versions of each function to build, and when CONFIG_RUNTIME_CPU_DETECT is enabled, the correct version is chosen at run time. In order for this to work, the CFLAGS must be set to something appropriate (e.g., without -mfpu=neon for ARMv7, and with appropriate -march and -mcpu for even earlier configurations), or the native C code will not be able to run. The ASFLAGS must remain set for the most advanced instruction set required at build time, since the ARM assembler will refuse to emit them otherwise. I have not attempted to make any changes to configure to do this automatically. Doing so will probably require the addition of new configure options. Many of the hooks for RTCD on ARM were already there, but a lot of the code had bit-rotted, and a good deal of the ARM-specific code is not integrated into the RTCD structs at all. I did not try to resolve the latter, merely to add the minimal amount of protection around them to allow RTCD to work. Those functions that were called based on an ifdef at the calling site were expanded to check the RTCD flags at that site, but they should be added to an RTCD struct somewhere in the future. The functions invoked with global function pointers still are, but these should be moved into an RTCD struct for thread safety (I believe every platform currently supported has atomic pointer stores, but this is not guaranteed). The encoder's boolhuff functions did not even have _c and armv7 suffixes, and the correct version was resolved at link time. The token packing functions did have appropriate suffixes, but the version was selected with a define, with no associated RTCD struct. However, for both of these, the only armv7 instruction they actually used was rbit, and this was completely superfluous, so I reworked them to avoid it. The only non-ARMv4 instruction remaining in them is clz, which is ARMv5 (not even ARMv5TE is required). Considering that there are no ARM-specific configs which are not at least ARMv5TE, I did not try to detect these at runtime, and simply enable them for ARMv5 and above. Finally, the NEON register saving code was completely non-reentrant, since it saved the registers to a global, static variable. I moved the storage for this onto the stack. A single binary built with this code was tested on an ARM11 (ARMv6) and a Cortex A8 (ARMv7 w/NEON), for both the encoder and decoder, and produced identical output, while using the correct accelerated functions on each. I did not test on any earlier processors. Change-Id: I45cbd63a614f4554c3b325c45d46c0806f009eaa
2010-10-21 00:39:11 +02:00
lsls r12, r12, #1 ; bb = v >> n
mul r6, r4, r7 ; ((range-1) * pp[i>>1]))
2010-05-18 17:58:33 +02:00
; bb can only be 0 or 1. So only execute this statement
; if bb == 1, otherwise it will act like i + 0
addcs lr, lr, #1 ; i + bb
mov r7, #1
ldrsb lr, [r10, lr] ; i = vp8_coef_tree[i+bb]
add r4, r7, r6, lsr #8 ; 1 + (((range-1) * pp[i>>1]) >> 8)
2010-05-18 17:58:33 +02:00
addcs r2, r2, r4 ; if (bb) lowvalue += split
subcs r4, r5, r4 ; if (bb) range = range-split
; Counting the leading zeros is used to normalize range.
clz r6, r4
sub r6, r6, #24 ; shift
; Flag is set on the sum of count. This flag is used later
; to determine if count >= 0
adds r3, r3, r6 ; count += shift
lsl r5, r4, r6 ; range <<= shift
bmi token_count_lt_zero ; if(count >= 0)
sub r6, r6, r3 ; offset = shift - count
sub r4, r6, #1 ; offset-1
lsls r4, r2, r4 ; if((lowvalue<<(offset-1)) & 0x80000000 )
bpl token_high_bit_not_set
ldr r4, [r0, #vp8_writer_pos] ; x
sub r4, r4, #1 ; x = w->pos-1
b token_zero_while_start
token_zero_while_loop
mov r10, #0
strb r10, [r7, r4] ; w->buffer[x] =(unsigned char)0
sub r4, r4, #1 ; x--
token_zero_while_start
cmp r4, #0
ldrge r7, [r0, #vp8_writer_buffer]
ldrb r11, [r7, r4]
cmpge r11, #0xff
beq token_zero_while_loop
ldr r7, [r0, #vp8_writer_buffer]
ldrb r10, [r7, r4] ; w->buffer[x]
add r10, r10, #1
strb r10, [r7, r4] ; w->buffer[x] + 1
token_high_bit_not_set
rsb r4, r6, #24 ; 24-offset
ldr r10, [r0, #vp8_writer_buffer]
lsr r7, r2, r4 ; lowvalue >> (24-offset)
ldr r4, [r0, #vp8_writer_pos] ; w->pos
lsl r2, r2, r6 ; lowvalue <<= offset
mov r6, r3 ; shift = count
add r11, r4, #1 ; w->pos++
bic r2, r2, #0xff000000 ; lowvalue &= 0xffffff
str r11, [r0, #vp8_writer_pos]
sub r3, r3, #8 ; count -= 8
strb r7, [r10, r4] ; w->buffer[w->pos++]
; r10 is used earlier in the loop, but r10 is used as
; temp variable here. So after r10 is used, reload
; vp8_coef_tree_dcd into r10
ldr r10, [sp, #60] ; vp8_coef_tree
token_count_lt_zero
lsl r2, r2, r6 ; lowvalue <<= shift
subs r8, r8, #1 ; --n
bne token_loop
ldrb r6, [r1, #tokenextra_token] ; t
2010-05-18 17:58:33 +02:00
ldr r7, [sp, #8] ; vp8_extra_bits
; Add t * sizeof (vp8_extra_bit_struct) to get the desired
; element. Here vp8_extra_bit_struct == 16
add r12, r7, r6, lsl #4 ; b = vp8_extra_bits + t
2010-05-18 17:58:33 +02:00
ldr r4, [r12, #vp8_extra_bit_struct_base_val]
cmp r4, #0
beq skip_extra_bits
; if( b->base_val)
ldr r8, [r12, #vp8_extra_bit_struct_len] ; L
ldrsh lr, [r1, #tokenextra_extra] ; e = p->Extra
2010-05-18 17:58:33 +02:00
cmp r8, #0 ; if( L)
beq no_extra_bits
ldr r9, [r12, #vp8_extra_bit_struct_prob]
asr r7, lr, #1 ; v=e>>1
ldr r10, [r12, #vp8_extra_bit_struct_tree]
str r10, [sp, #4] ; b->tree
rsb r4, r8, #32
Add runtime CPU detection support for ARM. The primary goal is to allow a binary to be built which supports NEON, but can fall back to non-NEON routines, since some Android devices do not have NEON, even if they are otherwise ARMv7 (e.g., Tegra). The configure-generated flags HAVE_ARMV7, etc., are used to decide which versions of each function to build, and when CONFIG_RUNTIME_CPU_DETECT is enabled, the correct version is chosen at run time. In order for this to work, the CFLAGS must be set to something appropriate (e.g., without -mfpu=neon for ARMv7, and with appropriate -march and -mcpu for even earlier configurations), or the native C code will not be able to run. The ASFLAGS must remain set for the most advanced instruction set required at build time, since the ARM assembler will refuse to emit them otherwise. I have not attempted to make any changes to configure to do this automatically. Doing so will probably require the addition of new configure options. Many of the hooks for RTCD on ARM were already there, but a lot of the code had bit-rotted, and a good deal of the ARM-specific code is not integrated into the RTCD structs at all. I did not try to resolve the latter, merely to add the minimal amount of protection around them to allow RTCD to work. Those functions that were called based on an ifdef at the calling site were expanded to check the RTCD flags at that site, but they should be added to an RTCD struct somewhere in the future. The functions invoked with global function pointers still are, but these should be moved into an RTCD struct for thread safety (I believe every platform currently supported has atomic pointer stores, but this is not guaranteed). The encoder's boolhuff functions did not even have _c and armv7 suffixes, and the correct version was resolved at link time. The token packing functions did have appropriate suffixes, but the version was selected with a define, with no associated RTCD struct. However, for both of these, the only armv7 instruction they actually used was rbit, and this was completely superfluous, so I reworked them to avoid it. The only non-ARMv4 instruction remaining in them is clz, which is ARMv5 (not even ARMv5TE is required). Considering that there are no ARM-specific configs which are not at least ARMv5TE, I did not try to detect these at runtime, and simply enable them for ARMv5 and above. Finally, the NEON register saving code was completely non-reentrant, since it saved the registers to a global, static variable. I moved the storage for this onto the stack. A single binary built with this code was tested on an ARM11 (ARMv6) and a Cortex A8 (ARMv7 w/NEON), for both the encoder and decoder, and produced identical output, while using the correct accelerated functions on each. I did not test on any earlier processors. Change-Id: I45cbd63a614f4554c3b325c45d46c0806f009eaa
2010-10-21 00:39:11 +02:00
lsl r12, r7, r4
2010-05-18 17:58:33 +02:00
mov lr, #0 ; i = 0
extra_bits_loop
ldrb r4, [r9, lr, asr #1] ; pp[i>>1]
sub r7, r5, #1 ; range-1
Add runtime CPU detection support for ARM. The primary goal is to allow a binary to be built which supports NEON, but can fall back to non-NEON routines, since some Android devices do not have NEON, even if they are otherwise ARMv7 (e.g., Tegra). The configure-generated flags HAVE_ARMV7, etc., are used to decide which versions of each function to build, and when CONFIG_RUNTIME_CPU_DETECT is enabled, the correct version is chosen at run time. In order for this to work, the CFLAGS must be set to something appropriate (e.g., without -mfpu=neon for ARMv7, and with appropriate -march and -mcpu for even earlier configurations), or the native C code will not be able to run. The ASFLAGS must remain set for the most advanced instruction set required at build time, since the ARM assembler will refuse to emit them otherwise. I have not attempted to make any changes to configure to do this automatically. Doing so will probably require the addition of new configure options. Many of the hooks for RTCD on ARM were already there, but a lot of the code had bit-rotted, and a good deal of the ARM-specific code is not integrated into the RTCD structs at all. I did not try to resolve the latter, merely to add the minimal amount of protection around them to allow RTCD to work. Those functions that were called based on an ifdef at the calling site were expanded to check the RTCD flags at that site, but they should be added to an RTCD struct somewhere in the future. The functions invoked with global function pointers still are, but these should be moved into an RTCD struct for thread safety (I believe every platform currently supported has atomic pointer stores, but this is not guaranteed). The encoder's boolhuff functions did not even have _c and armv7 suffixes, and the correct version was resolved at link time. The token packing functions did have appropriate suffixes, but the version was selected with a define, with no associated RTCD struct. However, for both of these, the only armv7 instruction they actually used was rbit, and this was completely superfluous, so I reworked them to avoid it. The only non-ARMv4 instruction remaining in them is clz, which is ARMv5 (not even ARMv5TE is required). Considering that there are no ARM-specific configs which are not at least ARMv5TE, I did not try to detect these at runtime, and simply enable them for ARMv5 and above. Finally, the NEON register saving code was completely non-reentrant, since it saved the registers to a global, static variable. I moved the storage for this onto the stack. A single binary built with this code was tested on an ARM11 (ARMv6) and a Cortex A8 (ARMv7 w/NEON), for both the encoder and decoder, and produced identical output, while using the correct accelerated functions on each. I did not test on any earlier processors. Change-Id: I45cbd63a614f4554c3b325c45d46c0806f009eaa
2010-10-21 00:39:11 +02:00
lsls r12, r12, #1 ; v >> n
mul r6, r4, r7 ; (range-1) * pp[i>>1]
2010-05-18 17:58:33 +02:00
addcs lr, lr, #1 ; i + bb
mov r7, #1
ldrsb lr, [r10, lr] ; i = b->tree[i+bb]
add r4, r7, r6, lsr #8 ; split = 1 + (((range-1) * pp[i>>1]) >> 8)
2010-05-18 17:58:33 +02:00
addcs r2, r2, r4 ; if (bb) lowvalue += split
subcs r4, r5, r4 ; if (bb) range = range-split
clz r6, r4
sub r6, r6, #24
adds r3, r3, r6 ; count += shift
lsl r5, r4, r6 ; range <<= shift
bmi extra_count_lt_zero ; if(count >= 0)
sub r6, r6, r3 ; offset= shift - count
sub r4, r6, #1 ; offset-1
lsls r4, r2, r4 ; if((lowvalue<<(offset-1)) & 0x80000000 )
bpl extra_high_bit_not_set
ldr r4, [r0, #vp8_writer_pos] ; x
sub r4, r4, #1 ; x = w->pos - 1
b extra_zero_while_start
extra_zero_while_loop
mov r10, #0
strb r10, [r7, r4] ; w->buffer[x] =(unsigned char)0
sub r4, r4, #1 ; x--
extra_zero_while_start
cmp r4, #0
ldrge r7, [r0, #vp8_writer_buffer]
ldrb r11, [r7, r4]
cmpge r11, #0xff
beq extra_zero_while_loop
ldr r7, [r0, #vp8_writer_buffer]
ldrb r10, [r7, r4]
add r10, r10, #1
strb r10, [r7, r4]
extra_high_bit_not_set
rsb r4, r6, #24 ; 24-offset
ldr r10, [r0, #vp8_writer_buffer]
lsr r7, r2, r4 ; lowvalue >> (24-offset)
ldr r4, [r0, #vp8_writer_pos]
lsl r2, r2, r6 ; lowvalue <<= offset
mov r6, r3 ; shift = count
add r11, r4, #1 ; w->pos++
bic r2, r2, #0xff000000 ; lowvalue &= 0xffffff
str r11, [r0, #vp8_writer_pos]
sub r3, r3, #8 ; count -= 8
strb r7, [r10, r4] ; w->buffer[w->pos++]=(lowvalue >> (24-offset))
ldr r10, [sp, #4] ; b->tree
extra_count_lt_zero
lsl r2, r2, r6
subs r8, r8, #1 ; --n
bne extra_bits_loop ; while (n)
no_extra_bits
ldr lr, [r1, #4] ; e = p->Extra
add r4, r5, #1 ; range + 1
tst lr, #1
lsr r4, r4, #1 ; split = (range + 1) >> 1
addne r2, r2, r4 ; lowvalue += split
subne r4, r5, r4 ; range = range-split
tst r2, #0x80000000 ; lowvalue & 0x80000000
lsl r5, r4, #1 ; range <<= 1
beq end_high_bit_not_set
ldr r4, [r0, #vp8_writer_pos]
mov r7, #0
sub r4, r4, #1
b end_zero_while_start
end_zero_while_loop
strb r7, [r6, r4]
sub r4, r4, #1 ; x--
end_zero_while_start
cmp r4, #0
ldrge r6, [r0, #vp8_writer_buffer]
ldrb r12, [r6, r4]
cmpge r12, #0xff
beq end_zero_while_loop
ldr r6, [r0, #vp8_writer_buffer]
ldrb r7, [r6, r4]
add r7, r7, #1
strb r7, [r6, r4]
end_high_bit_not_set
adds r3, r3, #1 ; ++count
lsl r2, r2, #1 ; lowvalue <<= 1
bne end_count_zero
ldr r4, [r0, #vp8_writer_pos]
mvn r3, #7
ldr r7, [r0, #vp8_writer_buffer]
lsr r6, r2, #24 ; lowvalue >> 24
add r12, r4, #1 ; w->pos++
bic r2, r2, #0xff000000 ; lowvalue &= 0xffffff
str r12, [r0, #0x10]
strb r6, [r7, r4]
end_count_zero
skip_extra_bits
add r1, r1, #TOKENEXTRA_SZ ; ++p
check_p_lt_stop
ldr r4, [sp, #0] ; stop
cmp r1, r4 ; while( p < stop)
bcc while_p_lt_stop
ldr r6, [sp, #12] ; mb_rows
ldr r7, [sp, #16] ; tokenlist address
subs r6, r6, #1
add r7, r7, #TOKENLIST_SZ ; next element in the array
str r6, [sp, #12]
bne mb_row_loop
str r2, [r0, #vp8_writer_lowvalue]
str r5, [r0, #vp8_writer_range]
str r3, [r0, #vp8_writer_count]
add sp, sp, #24
pop {r4-r11, pc}
ENDP
_VP8_COMP_common_
DCD vp8_comp_common
_VP8_COMMON_MBrows_
DCD vp8_common_mb_rows
_VP8_COMP_tplist_
DCD vp8_comp_tplist
END