Public SourceMage Discussion List

[Mark Andrews <msasgl AT msa-enterprises.com>]

Friday, October 4, 2002, 9:36:05 PM, Eric wrote:

ES> I have a few machines that are itching to
ES> be broken (besides my Sparc, which is having problems compiling gcc and
ES> the linux kernel...both are different problems :().

That reminds me.. Last night I was thinking about the cpudetect stuff
and realised that it shouldn't be a part of sorcery.

That's because what it is _really_ doing is creating a target for gcc.
So it should probably be a part of the gcc spell. In fact there is a
case to be made for moving all hardware specific stuff out of Sorcery
and into spells.

As I get further into the hardware detection stuff it would be a lot
easier if all I need to do is identify the spell required to support a
particular bit of kit, then let cast do the rest.. But that's a topic
for another day...

So back to GCC. If what I am doing is creating a target platform spec,
then we should define this more clearly and in an architecture
independant way. The current optimization routines in sorcery should
be redefined in a way that makes more sense and allows spells to
override the local settings easily. Is it glibc that needs -O2 instead
of -O3 for example?

I'm also questioning whether the current system of using bash scripts
to store variables like

VARIABLE=VALUE

Is truly viable in the long term. I know for me it makes the sorcery
code difficult to follow for debugging. I propose changing this to use

VARIABLE:VALUE

in reference tables the way my cpudetect code does. You'll be able to
see a full set of routines for this in the next release of cpudetect
as I'm going to create a "libvariables" for them. I'll add routines
for writing and for parsing the entire file into bash variables to
emulate the current system.

I suggest this for a number of reasons:-

1) It is immediately obvious where data values are coming from.

2) The includes in bash would only be needed for subroutines

3) grep-ing bash code for data variables seems dodgy at best and we
should stop this practice - currently it is the only way to get a
single variable from a file. I suspect it is something like this that
is causing cast to throw a funny with the autocpu code.

4) We can get the value of a variable and then override it without
worrying that another include will change it back. We should also
avoid silliness like archspecs being called six times for every cast.

5) bash variables can still be used where appropriate (paths?).

6) If it's good enough for the kernel routines...

So back to gcc. For all the above reasons, the next version of
cpudetect will primarily produce an output file which can then be used
by other bash scripts just by including the libvariables routines and
doing lookups to retrieve the specific values. I gave a lot of thought
to this and what values we need to be as cross-platform compatible as
possible. So here is the first draft of the new variables which will
be available, send comments & suggestions to the usual address:

Directory Structure:

./gcc/targets/$CPUARCH/$CPUTYPE
./gcc/targets/local

Each time cpudetect is run it will produce a target specific to that
system in local. By collecting these in /architecture for manual
selection, it becomes very easy to add a new target (and thus support
a new platform) for cross-compilation.

File Contents:

MANAGER: program name to edit/recreate this file (for automenu's)
CPUARCH: Architecture
CPUTYPE: Processor model
CPUNAME: Long Description of Processor
INSTALL: Options for installing gcc with support for this processor
FIRMWARE: GCC Flags for compiling firmware on this processor
KERNEL: GCC Flags for compiling kernels on this processor
LIBRARY: GCC Flags for compiling libraries on this processor
PROGRAM: GCC flags for compiling programs on this processor
OPTION1: "GCC Flags";"Description"
OPTION2: "GCC Flags";"Description"
OPTION3: "GCC Flags";"Description"
OPTION4: etc.. no fixed limit. use for each "^OPTION*:" loop to read.

Should be far more reliable and flexible than the current system. The
variable amount of OPTIONS would be for processor specific additional
options. And this opens the doors to supporting other compilers 8-)

Spells could then detail the type of code FIRMWARE|KERNEL| etc and
automagically get the right optimization settings for any supported
architecture / processor / compiler combination. Spells could change
the level eg KERNEL instead of LIBRARY with code like this:

include $MODULEPATH/libvariables  # probably in compiler specific
TARGET="$COMPILER/targets/local"  # subroutine called from cast

if  [  $(lookup "CPUARCH" $TARGET)  =  "pc"  ];  then
  # LIBRARY breaks on pc, use KERNEL
  $CFLAGS=$(lookup "KERNEL" $TARGET)
else
  $CFLAGS=$(lookup "LIBRARY" $TARGET) # default would really be
  # done by cast so wouldn't need the else here, just the first
  # change. we can assume "PROGRAM" unless the spell says otherwise
  # so all spells won't need a CODETYPE: setting in DETAILS ;-)
fi

Makes it easy to do specific fixes without breaking anything else..
Anyway, if the gcc maintainer or anyone else wants to have words
with me, you know where I am.

I think what I'm working on could actually turn out to be part of
SourceMage 2.0 but hey, with 1.0 just around the corner maybe now is
the time to get this going ;-)

So to recap, next cpudetect will contain:

libvariables  :  lookup and save routines
cpu2gcc       :  code to scan cpuinfo and produce TARGET file
cpu2gcc refs  :  lookup tables for auto target generation
autocpu       :  reads local TARGET and sets sorcery bash vars

This should work without any changes to sorcery, but lays the
foundation for this idea to be developed further.

-- 
Best regards,
 Mark                            mailto:msasgl AT msa-enterprises.com