On Wed, Nov 17, 2010 at 2:53 AM, Michael Hope <michael.h...@linaro.org> wrote:
> In general the product should move forward and drop work-arounds like
> -mimplicit-it. We (the greater ARM community) should fix these
> package problems as they are found. Here's a bunch of quick-fire
> statements:
>
> * Qt is currently broken on ARM multiprocessor systems
> * Qt provides a QAtomic class which provides atomic functions on
> integers and pointers
> * You can call different functions depending on your ordering constraints
> * GCC's __sync primitives are ordered only
> * The ARMv6 QAtomic implementation only provides ordered versions
> * AVR32 currently uses the sync primitives in the same way
>
> So there's a precedent there for __sync primitives and they'd be
> equivalent to what is already there. If RVDS also supports __sync_*
> (Richard?) then we can also delete the RVDS specific code.
>
> The kernel adds -mimplicit-it via its own build rules. What else
> needs -mimplicit-it? Matthias, are you running a rebuild at the
> moment? How many extra packages have failed?
>
> I had a play with the Maverick GCC-4.5 and binutils. This code:
>
> void foo()
> {
> asm("it eq\n\t"
> "teqeq r2,#1"
> );
> }
>
> compiles fine with -marm, -mthumb, and -march=armv4t -marm. It seems
> the assembler accepts IT instructions in both unified and
> compatibility modes.
Interesting... it this is indeed true then it could provide a way
forward. I don't know which binutils versions will support this --
Richard may be able to comment.
Note that -mimplicit-it is a sort of anti-workaround: I believe the
design intent of the unified assembler syntax was that programmers
should not normally write IT explicitly (since that obviously makes
code harder to port and maintain ... as we're discovering). So the
native behaviour of the RVCT assembler is the like the implicit-it
behaviour, and gas (and GCC inline asm) are incompatible with this
behaviour by default.
Of course, there's no technical reason why the behaviour has to be the
same across different toolchains, but since the alternative is to
patch all the inline assembler in the world ... and out-of-line
assembler too if we want to migrate that to thumb ... and since the
kernel at least is unlikely to do this, it does at least seem worth
trying to make the case to upstream.
Of course, it's possible this has all been tried before and will be a
foregone conclusion... so if people still disagree then that's fair
enough.
If all gas that we care about accept IT instructions in separated
syntax mode, then this does at least make it feasible to put the ITs
in manually without resorting to preprocessor hacks. But it may still
be a lot of work.
Cheers
---Dave
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
