On Mon, 17 Mar 2014, Janne Grunau wrote:
On 2014-03-17 12:17:46 +0200, Martin Storsjö wrote:
On Mon, 17 Mar 2014, Janne Grunau wrote:
On 2014-03-17 10:56:49 +0200, Martin Storsjö wrote:
This does some rudimentary conversions of instructions that aren't
available in thumb mode.
This allows building OpenH264 for Windows Phone 8 (and Windows RT),
which only supports thumb mode, and the OpenH264 arm assembly is
hardcoded for arm mode.
This is similar to how libvpx supports assembling in thumb mode - the
source itself is arm mode only, but a perl script can replace
instruction combinations that aren't supported in thumb mode. This
is a small subset of those conversions.
---
gas-preprocessor.pl | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index 3d1049b..bbc5ff4 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -883,6 +896,24 @@ sub handle_serialized_line {
$line =~ s/&0x/& 0x/g;
}
+ if ($force_thumb) {
+ # Convert register post indexing to a separate add instruction.
+ # This converts "ldrneb r9, [r0], r2" into "ldrneb r9, [r0]",
+ # "add r0, r2".
+ $line =~
s/^(\s*)((ldr|str)(ne)?[bhd]?)(\s+)(\w+),(\s*\w+,)?\s*\[(\w+)\],\s*(\w+)/$1$2$5$6,$7
[$8]\n$1add$4$5$8, $8, $9/g;
They're quite open to patches, but they are actually already using
unified syntax.
UAL syntax for ldrneb would be ldrbne which we should use. But if
openh264 doesn't use conditionals in matching instructions I would
just omit it for now.
This would be as function more readable considering that it might
need to be extended. Missing are condition codes, the sign
extending byte/half-word loads/stores and '!'
You mean moving all of these thumb fixups to a separate function, or
how should I make it more readable?
The ldr|str regexp itself, '$1$2$5$6,$7 [$8]' is not readable, variable
names could help.
Maybe not capturing whitespace and commas and handling ldrd/strd in its
own regexp would be enough.
Indeed it isn't. For the libvpx conversion (which isn't done on the fly as
with gas-pp but in a separate step in the build) I tried to keep the same
indentation to keep the converted result as readable as possible, but it
indeed impacts the readability quite much.
By not capturing the whitespace, skipping the conditional codes and
handling of the b/h/d cases (especially the ldrd case which has an extra
register parameter compared to the others), it becomes much more readable.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
