On Mon, Feb 24, 2003 at 06:05:27PM -0500, Camm Maguire wrote:
Hi,
> If you like the idea or something similar, may I ask your help in
> advocating its consideration on debian-devel and any other appropriate
> place?
I took quite some time to think about your proposal and related
issues.
As I understand it, your proposal pushes most of the responsibility to decide
whether and how to multilib a certain package as well as the actual work
(munging Makefiles etc) to the packager of the Debian package, this has
drawbacks:
- it is distribution specific
- requires intimate knowledge of all supported architectures,
compilers and the requirements of the software from the person
deciding about the packaging
thus in practice I would expect only few packages for the most important
architectures would get fixed this way.
What would be more effective is to create a īconfig-multilibī script that
would enable software authors to use the multilib scheme without requiring
each of them to have intimate knowledge of all possible architecture and
distribution specific details.
So ideally īconfig-multilibī could do:
(a) Suggest a list of target variants recommended when optimising
for specific features
# config-multilib --optimise-for LONGLONG INTEGER_ARRAY
68020-40
68060
# config-multilib --optimise-for FLOAT DOUBLE
68020-30
68040
68060
# config-multilib --optimise-for INTEGER
GENERIC
(a1) (only for complex packages)
Get a breakdown of conflicting optimisation requirements so that
different parts of the package can be compiled with different
optimisation techniques where required.
This would cater for the rare cases where eg the use of some ISA
extensions contradicts the use of other optimisations. I donīt think
there is such a thing on m68k so I donīt have any good example handy,
but pretty sure the SIMD optimisations of some architectures have
such limitations. For this example lets assume that integer-array
and float/double optimisations donīt go together very well on some
architecture but longlong works well with both of them:
# config-multilib --breakdown-requirements INTEGER_ARRAY LONGLONG FLOAT DOUBLE
INTEGER_ARRAY LONGLONG
FLOAT DOUBLE LONGLONG
This would mean that the parts using INTEGER_ARRAY and LONGLONG
need to be built with different options than those using FLOAT
and DOUBLE
Possibly I am just plain overengineering here and this step could
be left out completely.. most likely the software will already be
organised in such a way that there arenīt any such conflicting
options and if it isnīt than there is very little what an
automated build system could do about it except give a warning.
(b) hint the best compilation flags
# config-multilib --cflags 68020-40 LONGLONG INTEGER_ARRAY
-m68020-40
# config-multilib --cflags GENERIC LONGLONG INTEGER_ARRAY
-m68020-60
# config-multilib --lflags 68020-40 LONGLONG INTEGER_ARRAY
-L /usr/lib/68020-40
(c) give information how to best install multilibs on this architecture
and distribution, I think this was partly covered your proposal.
So the config/build process could be easilly adapted to create the best
target variants with the best optimisation settings practically without
any knowledge of the target architecture, and without hardcoding
tons of assumptions about compiler capabilities into the package.
Some subclassing scheme with the usuall inheritance would be usefull
to handle the features. In one example above I used INTEGER but it is
obvious that INTEGER-ADD may be generic while INTEGER-DIV may need
target variants on some architectures - early RISC CPUs often didnīt
have integer division instructions.
So we would have something like this (absolutely nonexhaustive) hierarchy
of features/capabilities:
INTEGER
INTEGER-ADD
INTEGER-MUL
INTEGER-DIV
INTEGER-BITOP
INTEGER-SHIFT
LONGLONG
LONGLONG-ADD
LONGLONG-MUL
LONGLONG-DIV
GENERAL_FLOAT
DOUBLE
DOUBLE-MULADD
DOUBLE-SQRT
DOUBLE-TRIG
DOUBLE-EXP
DOUBLE-LOG
FLOAT
FLOAT-MULADD
...
...
...
STRING
I have probably overengineered it quite a bit as I do usually ;)
Richard
