Re: ARM EABI port: minimum CPU choice
Hi again
I've been looking at the options we were talking about to make the
ARM Debian EABI port work on armv4 as well as armv4t and above and it
seems to me that there is a simpler solution.
Rather than have me mangle gcc to support new function exit sequences,
with all the possibility of introducing subtle bugs that that entails,
can we not simply compile the standard Debian ARM EABI port for armv4
with -mno-thumb-interwork? That should work fine on everything, not
add extra instructions and slowness for everyone and, according to the
GCC manual page, will also remove a small size and speed overhead that
interworking-capable code incurs.
(Note: in ARM GCC, -mno-thumb-interwork is the default, while with
EABI it is -mthumb-interwork)
What is lost is the ability to compile a program in Thumb mode and
link it against the standard Debian libraries. I would think that
people who need space optimisation would do better to join the people
who build their own repositories optimised for their specific CPU
(which will give thumb-capable repositories for all thumb-capable
CPUs).
In any case, you would get a much greater space reduction by building
(or using) a pure-Thumb repository than by just recompiling the
biggest applications in thumb mode and using the standard libraries
and utilities.
Does anyone really win by having us bulk out and slow down the whole
distro a ilttle with thumb capability so as to be able to compile just
one or two programs in thumb mode?
I know the ARM EABI spec "mandates thumb interworking", but supporting
it seems to be making us make several global slowdowns for it in the
Debian port to gain a minor ability of dubious value, compared to just
saying -march=v4 -mno-thumb-interwork and having optimal armv4 code
for everyone.
Opinions?
M
Reply to: