On Thu, 20 Mar 2014, Ben Avison wrote:

On Thu, 20 Mar 2014 07:33:10 -0000, Martin Storsjö <[email protected]> wrote:
Just to be clear, the tricks that don't work in thumb mode are non-
constant shifts, and jump tables with "ldr pc, [pc, ...]", right?

Yes, it looks like it. I admit, Thumb was something of an afterthought;
shortly before I released it I had a try at assembling it as Thumb and
saw multiple issues; switching to using ARM was the quick and easy
solution. Or so I thought...

Forcing arm mode like this isn't ok in all configurations - e.g. when
building for WinRT/Windows Phone 8, you really have to build all of it
in thumb mode; the linker doesn't handle everything needed for mixing
the modes there.

I would consider that a tools bug, myself. There's no architectural
reason why interworking wouldn't work on anything except a Cortex-M CPU
(which isn't the sort of thing you'd run libav on, especially a TrueHD
decoder - far too low power). My assembly functions are called through
function pointers, not BL statements, and ever since ARMv5 all loads to
the PC (which is how you use a function pointer) are treated as
interworking branches. Before ARMv5, the Thumb instruction set wouldn't
have been rich enough to assemble the sources anyway.

Yeah, architecturally there shouldn't be any issue, but they've more or less speced their environment to be thumb-only and that's all the tools care about. I'm not familiar enough with all the intricacies with interworking to figure out in which cases it works and what's missing in practice - I've only tested it lightly and got the general picture of "some things might work, but not everything".

However, I doubt I'll have much luck persuading Microsoft of the error of
their ways, so I have made the following changes:
* added IT statements where necessary
* replaced the branch tables with TBH branch tables when targeting Thumb
* where possible, replaced the ALU-op-with-register-shifted-register
instructions with Thumb-compatible sequences when targeting Thumb

It wasn't possible to convert one family of functions, though - the 18
ff_mlp_pack_output_outoforder_*ch_*shift_armv6 functions. There were no
spare registers which could be used as temporaries there, so supporting
Thumb would mean a major change to register allocation, which I haven't
attempted. Instead, I have switched out those functions when CONFIG_THUMB
is defined. (Yes, I saw the discussion about adding an interworking
switch - I'm not sure it's warranted now that most of the optimisations
work in Thumb mode.)

This sounds like a quite sensible thing to do.

Now it remains for me to fix up gas-preprocessor to the point that this assembles correctly via that tool as well. As far as I've seen now with the previous iterations, there's one issue about in which order the nested ifs/macros are evaluated that need to be tweaked.

// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to