sm-sorcery AT lists.ibiblio.org
Subject: Discussion of Sorcery related topics
List archive
Re: Re[2]: [SM-Sorcery]Architecture Selection Code - Will this work?
- From: Dufflebunk <dufflebunk AT dufflebunk.homeip.net>
- To: Mark Andrews <msasgl AT msa-enterprises.com>
- Cc: Wolfgang Scheicher <worf AT sbox.tu-graz.ac.at>, sm-sorcery AT lists.ibiblio.org
- Subject: Re: Re[2]: [SM-Sorcery]Architecture Selection Code - Will this work?
- Date: 01 Oct 2002 14:07:15 -0400
Unfortunatly the guy who worked on the compiler and created that
directory is away and without internet access for a week or two.
On Tue, 2002-10-01 at 05:46, Mark Andrews wrote:
> Hello Wolfgang,
>
> Monday, September 30, 2002, 8:10:46 PM, you wrote:
>
> MA> I've just been looking at the best place to put my auto-processor
> MA> selection code.
>
> WS> is this for general hardware detection or for compiler flag stuff?
>
> Both.
>
> WS> because for the compiler optimisation settings i would be careful.
>
> With this implementation the auto option is an add on to the current
> optimisation menus, that way novice users (and probably nearly
> everyone else if this works as well as I think it will) can use auto
> which will be specific to their machine. Advanced users can continue
> to use the current system and hand select exactly what they want if
> they prefer i586 code to Athlon for example.
>
> The whole point of gathering the cpuinfo is so I can be careful and
> automagically pick the exact optimisation settings that work best on
> that processor. This is early doors on this project, but believe me I
> am looking for the simplest, most reliable implementation I can.
>
> The code:-
> CPUNAME=`egrep "model name" /proc/cpuinfo | cut -d: -f2 | uniq`
> was just an example of what I might be doing in the routine to
> illustrate my point. The final code will be different to this (need to
> allow for SMP) and the optimisation flags will be generated from a
> series of checks and possibly user input if it can't be avoided. At
> the moment it looks like a different "auto" script will be needed for
> each architecture.
>
> Hence why I want to know where the archspecs files are called from. I
> really need to know if I can do things like - prompt the user for input
> in an archspecs routine / provide non standard optimisation options -
> or whether that will break things. Yes I will look at the code, but I
> figure someone already knows where archspecs are hooked and can tell
> me where to start. Saves time and it lets me focus on the new stuff
> I'm doing.
>
> WS> maybe default to i386/486/586/686, but not that athlon stuff - or at
> least
> WS> ask... and we should find out what code runs on what machine - and
> display
> WS> that info... rebuilding the whole thing is quite a task - and i would
> not
> WS> like to do it too often.
>
> Me neither. That's what started this. If the computer can detect the
> best options itself then we can use them from the install onwards and
> lack of user knowledge is less of a problem. For example, I didn't
> know if my processor had an APIC or not when I compiled my kernel so I
> said yes. If I'd known then about cpuinfo then I could have just
> looked at 'flags' in /proc/cpuinfo, seen that 'apic' wasn't there
> and known I didn't need APIC. Better still if sorcery had done it for
> me ;-)
>
> That's why I said both general hardware detection and compiler flag
> stuff. When I started looking at the processor detection possibilities
> I was just thinking optimisation settings. Then I saw that it can be
> used for other things too. Why ask the user questions when the
> computer can figure out the answer itself?
>
> --
> Best regards,
> Mark mailto:msasgl AT msa-enterprises.com
>
> _______________________________________________
> SM-Sorcery mailing list
> SM-Sorcery AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-sorcery
--
Quidquid latine dictum sit, altum sonatur.
-----------------
PGP public key at
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3327A9A5
F1
Attachment:
signature.asc
Description: This is a digitally signed message part
-
Re[2]: [SM-Sorcery]Architecture Selection Code - Will this work?,
Mark Andrews, 10/01/2002
- Re: Re[2]: [SM-Sorcery]Architecture Selection Code - Will this work?, Dufflebunk, 10/01/2002
Archive powered by MHonArc 2.6.24.