[uClibc] Bug 385, add Thumb support to ARM

[John Bowler]

From: Mike Frysinger [mailto:vapier at gentoo.org]
>hmm, so we would want to throw -mthumb-interworking into CFLAGS
with -mthumb
>right ?

All four combinations are valid.  The reasons for not
including -mthumb-interworking are:

1) In the current GCC implementation it adds a little code to uClibc (a few
hundred bytes? - everything protected by __THUMB_INTERWORK__).
2) If it is specified in the build of one module then *not* in another the
linker generates whine messages - that's actually a serious problem because
it would certainly generate large numbers of 'why does the compiler say
this' emails...

I don't believe that -mthumb-interwork causes run-time or code-space
overhead unless arm<->thumb transitions occur but I might have got this
wrong.  (I.e. I think arm->arm and thumb->thumb function calls just BL to
the function, as before).

>is the idea to (in the future) have uClibc be able to generate 100%
>thumb code ?

That's my idea.  Of course if the result is *significantly* slower for real
test cases I might back off from doing this, but I have a funny feeling it
will be faster because of the I-cache enhancement (40% more instructions in
the cache...)

Thumb drystone on a 266MHz (de-underclocked) NSLU2 is 3.5us per loop,
compared to 3us per loop for arm (same compiler, same options, just -mthumb
changed.)  That is, however, a thumb dhrystone calling arm string functions
(from an arm uClibc built non-optimised - i.e. *neither* the arm assembler
*nor* the GNU generic implementations.)  It's not really possible to draw
any conclusions yet...

John Bowler <jbowler at acm.org>