Re: discussion reset! thumb2/thumbee code as on armv7-a
On Thu, Jul 15, 2010 at 1:11 PM, Paul Brook <paul@codesourcery.com> wrote:
>> Lets take a step back on the naming.
>>
>> Let's say for example that we decide to use the fact that ThumbEE is a
>> required component on the ARMv7-A profile.
>>
>> My qualm with Thumb code on ARM is that it requires all libraries and
>> executables to be compiled with a compatible ABI in the first place.
>
> Huh? That's the whole point of the EABI. One of the core requirements is that
> code be interwoking safe, i.e. you can mix ARM and Thumb code freely.
Okay..
>> This means that everything gets prepended with the thumb interworking
>> which is maybe a register move and an extra branch, or a different
>> kind of branch (bx instead of bl?), and some weird little trampolines
>> in places to make sure one ISA can call the other.
>
> That's only really true on armv4t. Armv5 introduced a couple of changes that
> mean interworking is for most practical purposes free.
Okay so.. I recall Debian armel is built for armv4. Case in point.
> Thumb-2 is an extension of Thumb-1 that adds a bunch of new instructions
> (mostly using 32-bit encodings). On older cores these encodings were
> undefined. The new encodings implement functionality that is mostly
> equivalent to that in ARM mode. ARM and Thumb-2 encodings are not the same.
>
> Thumb-2EE is an additional new CPU mode. It implements a variant of Thumb-2
> tailored towards dynamically compiled code (e.g. JVM JITs). It replaces some
> instructions (mostly the privileged ones), and modifies the semantics of
> others.
Okay, but basically ThumbEE (and therefore Thumb2) is a required thing
on ARMv7 so, I would assume, it is safe to assume that any chip using
the architecture is going to be good for this.
> Choice of ISA is independent of the ABI. Generally speaking ARM code is still
> faster. This is another instance of where you want multiple builds of the
> same package within the same port, so users can choose between
> speed (-marm -O2) and size (-mthumb -Os) optimized builds.
I really don't like the idea of having two sets of the same code
running just on different ISAs for the sake of it. Pick one, stick
with it :)
ARM seems set on the idea from all their powerpoints and presentations
that at the very least, Thumb2 performance is approaching ARM code,
can use all the features without much restriction, but still gets a
good code density approaching Thumb... the idea being you may as well
build your entire system with it, because it's awesome? There's not a
lot of point making the decision do I want it in ARM mode or Thumb2
mode..
So, if we compile -mthumb, the question is do you really need to
compile with -Os? What I've noticed more and more is that the data
that comes with an application far exceeds the benefit of having
better code density provided by -Os. You lose your loop unrolling and
other benefits of higher -O levels.. caches are getting bigger and if
we stick to ARMv7.. you can guarantee the processors that fit the
baseline and the applications the port is for (smartbooks,
smartphones!) have gigabytes of backing storage and a good deal of RAM
(~256MB) to spare.
At the point someone is trying to save a few kilobytes to fit it into
the instruction cache they'd be recompiling the system from scratch
and using buildroot or scratchbox or ltib/atk or something and not
Debian. We have to sort of focus the port.
But anyway, the point of the question: would it be worth sticking to
Thumb2 as the ISA for the entire base system, or just stick to ARM? It
seems you'd prefer to just stick to ARM and let Thumb2 stuff get
chucked in afterwards for things that really really prefer it.
But, does that require extra compiler args in the base cflags or is
-mthumb-interworking the default, what's the impact on building?
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
Reply to: