[RFC] Enable tune-thumb.inc for all armv5t and armv6t machines

[RFC] Enable tune-thumb.inc for all armv5t and armv6t machines

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Today I seperated the thumb bits from conf/machine/include/ipx4xx.conf into
conf/machine/include/. I'd like to enable for all >=v5t machines, but I'm unsure about
using positive or negative logic.

* positive logic: might break for (soft)fpa distros that don't disable it, no problem for
EABI distros
* negative logic: no difference to status quo, but having negative logic in tune-* files
feels a bit wrong.

If you need numbers: http://ewi546.ewi.utwente.nl/tmp/thumb/comparison.txt (package:
<thumb size> <regular size> (<unit>))

what do you all think?

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFisNmMkyGM64RGpERAuh4AKC8UlGx15HTLJFrqRY9HKJoM1iKXACdEznx
VN+VBxsPrhMx8p6cOVGIgwg=
=tUsi
-----END PGP SIGNATURE-----

Re: [RFC] Enable tune-thumb.inc for all armv5t and armv6t machines

[Paul Sokolovsky]

Hello Koen,

Thursday, December 21, 2006, 7:24:54 PM, you wrote:

> Hi,

> Today I seperated the thumb bits from
> conf/machine/include/ipx4xx.conf into
> conf/machine/include/. I'd like to enable for all >=v5t machines, but I'm unsure about
> using positive or negative logic.

  What about armv4t?

> * positive logic: might break for (soft)fpa distros that don't disable it, no problem for
> EABI distros
> * negative logic: no difference to status quo, but having negative logic in tune-* files
> feels a bit wrong.

  It's very nice to see ("real") thumb support being added to OE in
general! But I guess, it's too bold a step to switch to it be the
default. There're usual risk management issues (who knows what bugs
CPUs/software have regarding thumb), plus, thumb has known drawback of
reduced performance.

  In ideal case, thumb usage would be set per-package, with most
of libraries being normal code, and most apps - thumb (and in this
case thumb can be indeed the default).


> If you need numbers:
> http://ewi546.ewi.utwente.nl/tmp/thumb/comparison.txt (package:
> <thumb size> <regular size> (<unit>))

  Using ipk sizes is of course pretty heuristical ;-). IMHO, those
sizes are not too much convincing at all, but I'm sure raw exe sizes
are better, and striving for that ideal case is worthy task ;-)

> what do you all think?

> regards,

> Koen


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: [RFC] Enable tune-thumb.inc for all armv5t and armv6t machines

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sokolovsky schreef:
> Hello Koen,
> 
> Thursday, December 21, 2006, 7:24:54 PM, you wrote:
> 
>> Hi,
> 
>> Today I seperated the thumb bits from
>> conf/machine/include/ipx4xx.conf into
>> conf/machine/include/. I'd like to enable for all >=v5t machines, but I'm unsure about
>> using positive or negative logic.
> 
>   What about armv4t?

The codesourcery people are telling horror stories to everyone about armv4t, but I don't
believe them anymore after
http://www.openembedded.org/repo/org.openembedded.dev/packages/gcc/gcc-4.1.1/unbreak-armv4t.patch
'fixed' EABI on armv4t. I get the distinct feeling csl is trying to strongarm people into
using armv5 and armv6.

>  plus, thumb has known drawback of reduced performance.

I know the 'bx' insn causes a pipeline flush on xscales, any other drawbacks? And more
importantly, any numbers?


> In ideal case, thumb usage would be set per-package

Yes, that's where ARM_INSTRUCTION_SET comes in :), although enabling it is messier as
disabling it.
I wasn't impressed by the numbers[1], but samba lost 0.5MB, so that's a candidate

regards,

Koen

[1] Ångström already uses -Os, so the binaries are already pretty small
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFitC+MkyGM64RGpERAtKJAKCdc1K3PuY8xMYrqhY7rvSR37+DuwCgo243
AKRNY2KVB7q8VsxoUDAmJY8=
=cau0
-----END PGP SIGNATURE-----

Re: [RFC] Enable tune-thumb.inc for all armv5t and armv6t machines

[Paul Sokolovsky]

Hello Koen,

Thursday, December 21, 2006, 8:21:50 PM, you wrote:

[]

>>> Today I seperated the thumb bits from
>>> conf/machine/include/ipx4xx.conf into
>>> conf/machine/include/. I'd like to enable for all >=v5t machines, but I'm unsure about
>>> using positive or negative logic.
>> 
>>   What about armv4t?

> The codesourcery people are telling horror stories to everyone about armv4t, but I don't
> believe them anymore after
> http://www.openembedded.org/repo/org.openembedded.dev/packages/gcc/gcc-4.1.1/unbreak-armv4t.patch
> 'fixed' EABI on armv4t. I get the distinct feeling csl is trying to strongarm people into
> using armv5 and armv6.

>>  plus, thumb has known drawback of reduced performance.

> I know the 'bx' insn causes a pipeline flush on xscales, any other drawbacks? And more
> importantly, any numbers?

  Well common Thumb intros usually have something like "Using Thumb
can usually reduce code size 1.5 times, while reducing performance by
20% because of longer instruction sequences for some operations.".
Or at least so I think. Because it turned out surprisingly hard to
find a link for that ;-). I finally found a pretty good academic
report: http://www.cs.arizona.edu/~gupta/research/Publications/Comp/L14-krishnaswamy.pdf

"""
While the use of Thumb instructions generally gives smaller code
size and lower instruction cache energy, there are certain problems
with using the Thumb mode. In many cases the reductions in code
size are obtained at the expense of a significant increase in the number
of instructions executed by the program. In our experiments
this increase ranged from 9% to 41%.
"""

  As each thumb instr maps to one ARM, those percentages are exactly
performance loss. So, we don't really want Thumb for gstreamer,
mpalyer, and glibc (sic!, way to reduce libc's footprint is obviously
to use uclibc ;-)).

  Two other common benefits of Thumb quoted are reduced memory
bandwidth requirements (like, can use 16bit memory), and cache
efficiency (including power) - but before we start optimize cache
usage, there'er few more significant things to do, like supporting
CPU idle modes, using dynticks, etc.


  So, two criteria above doesn't apply to us much, and indeed, it
appears that Thumb vs ARM instr. set is code size vs code
performance dichotomy in our case.


>> In ideal case, thumb usage would be set per-package

> Yes, that's where ARM_INSTRUCTION_SET comes in :), although enabling it is messier as
> disabling it.
> I wasn't impressed by the numbers[1], but samba lost 0.5MB, so that's a candidate

  Ok, good plan.

> regards,

> Koen

> [1] Angstrom already uses -Os, so the binaries are already pretty small

[]


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: [RFC] Enable tune-thumb.inc for all armv5t and armv6t machines

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sokolovsky schreef:
> Hello Koen,
> 
> Thursday, December 21, 2006, 8:21:50 PM, you wrote:
> 
> []
> 
>>>> Today I seperated the thumb bits from
>>>> conf/machine/include/ipx4xx.conf into
>>>> conf/machine/include/. I'd like to enable for all >=v5t machines, but I'm unsure about
>>>> using positive or negative logic.
>>>   What about armv4t?
> 
>> The codesourcery people are telling horror stories to everyone about armv4t, but I don't
>> believe them anymore after
>> http://www.openembedded.org/repo/org.openembedded.dev/packages/gcc/gcc-4.1.1/unbreak-armv4t.patch
>> 'fixed' EABI on armv4t. I get the distinct feeling csl is trying to strongarm people into
>> using armv5 and armv6.
> 
>>>  plus, thumb has known drawback of reduced performance.
> 
>> I know the 'bx' insn causes a pipeline flush on xscales, any other drawbacks? And more
>> importantly, any numbers?
> 
>   Well common Thumb intros usually have something like "Using Thumb
> can usually reduce code size 1.5 times, while reducing performance by
> 20% because of longer instruction sequences for some operations.".

Yeah, that's what you'd usually see. When I was attending a talk about DSPs[1] at SPS, the
speaker declared "[..] using thumb for better performance." which amused me and other
attendees :)

It's all about which kool-aid you drink.

regards,

Koen

[1] http://acivs.org/sps2006/AbstractList.php?type=regular#159
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFi6LUMkyGM64RGpERAiyGAKCoIoe0p2tAqbJ1J6iPPFnIghzcWACfXdt/
QK9W1UbPFtwgqKc4iiF+Fn8=
=2vJM
-----END PGP SIGNATURE-----