Re: [Gcl-devel] Re: gcc-3.2 problems in compiling GCL

[Richard Zidlicky <rz@linux-m68k.org>]

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