Re: ARM EABI port: minimum CPU choice
Martin:
Martin Guy wrote:
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
Rather, *a* main repository must be pure 32-bit. We have that today. I
understand that.
, 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.
... and that's all I'm asking for: formal support for an interworking
ARM repo, along with thumb packages so that users can pick-and-choose
ARM vs. Thumb for the packages they need.
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.
Not sure your generality holds, but part of your point is well made:
that a Thumb-capable host will have portions of the system in Thumb, and
others in ARM. Thus, you need a base platform with interworking
enabled. You then would install ARM or Thumb packages as the system
needs dictated.
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.
... which is what I'm asking for.
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?
To get *any* Thumb, you can't have a wholly 32-bit Debian ARM system.
So we need an arch that has interworking. You say that interworking is
too expensive to include in the ARM-only arches, so I'm proposing that
we add separate arches that have it so that the current arches won't
need to add it. Maybe:
armel, armeb -- ARM
armtel, armteb -- ARM/Thumb (interworking)
That gets you an all-ARM or all-Thumb system. I don't know yet how to
provide packages in both ARM and Thumb formats so that the armtel/armteb
systems can select from them. But I'm not a packaging guru, either...
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...
I know. :)
But I'm not entirely sure that interworking is as expensive as you make
it out to be, at least on *some* ARM targets. What I was saying when I
wrote that is that it might be a good idea to figure out which those
targets are, maybe over time we'll be able to clean things up to the
point that we could drop the ARM/Thumb arches, and add interworking to
the ARM arches. Just a thought.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
Reply to: