On Thu, Jul 15, 2010 at 1:11 PM, Paul Brook <p...@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 <m...@genesi-usa.com> Product Development Analyst, Genesi USA, Inc. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimmkjirpu8pbygcbgdrnguifkuwkjzfallyg...@mail.gmail.com
