Re: ARM EABI port: minimum CPU choice
2006/7/24, Bill Gatliff <bgat@billgatliff.com>:
Martin Guy wrote:
> but my question remains "is Thumb compatibility
> really worth all the trouble and risk and bloat in the context of
> generic Debian?" I think not.
I think it's worth the while to have a Thumb-capable Debian.
Why?
The main repository must be pure 32bit to work on non-thumb
processors, and users of that standard repo can only use Thumb by
compiling their own additional apps or by rebuilding individual
packages, which doesn't really save them much unless they recompile
all the base system and libraries to use it. At that point they might
as well make (or use) an interworking Thumb Debian repo and just
compile their speed-critical fragments in 32-bit mode, which is the
correct way to use an ARM/Thumb mix.
The correct way to use an ARM/Thumb mix to gain size and speed
advantage is to compile everything in Thumb and use 32-bit ARM code
fragments in the speed-critical parts. Doing it the other way round
(a mostly 32-bit system with Thumb fragments) defeats the point of
Thumb, gaining nothing in speed and very little in size, especially if
you factor in the extra overhead in size and speed for every single
function(-call) in the whole system.
I agree it would be nice to include the feature if it cost nothing,
but it seems to me to impose a cost on every single user in size,
speed and complexity (hence more bugs), and doesn't achieve the whole
point of Thumb... that would only be achieved by a separate Thumb arch
with interworking so that users can include 32-bit fragments.
So... is there a valid need for anyone to be able to include fragments
of Thumb code in an otherwise wholly 32-bit Debian ARM system? A
reason so pressing and of such widespread usefulness to outweigh the
global disadvantages of including interworking?
goes on we'll figure out how to make the non-T arches thumb-compatible?
Thumb emulation via illegal instruction traps? No, I'm only joking...
M
Reply to: