>>      On Wed, 5 Aug 2009 12:19:23 +0200 Roland Smith
>> >On Wed, Aug 05, 2009 at 10:54:07AM +0100, David Southwell wrote:
>> >> I have found
>> >> http://docs.freebsd.org/info/gcc/gcc.info.Optimize_Options.html.
>> >>
>> >> I am about to build a new kernel am starting to dig a bit deeper
>> >> things I have, until now, taken for granted.
>> >>
>> >> The above link is very informative in technical terms about how to
>> >> control optimization but I find it difficult to interpret the info
in a
>> >> way that tells me what might work best on my own system (Intel
>> >> Core) with 8G of ram.
>> >
>> >The build system takes care of that, once you have set the correct
>> >CPUTYPE in /etc/make.conf. For a quad-core, set CPUTYPE=nocona. See
>> >make.conf(5), /usr/src/share/mk/bsd.cpu.mk and
>> >/usr/src/sys/conf/kern.pre.mk.
>>      As I read the man page for [g]cc, though, setting -march=nocona
>> is where the CPUTYPE information ends up in the cc commands) tells
>> compiler which base instruction set to use and which model of
>> scheduling to use, but to get the rest of the model-dependent
>> used, he would still need to add "-mmmx -msse -msse2 -msse3" at a
>> for most other compilations, though these would not be advisable for
>> compilations.  I don't recall whether SSE4 instructions are in the
>> Merom/Kentfield chips or first appear in the Core i7 series.  I don't
>> the compiler versions available under FreeBSD support the SSE4
>> instructions, though, so SSE4 doesn't matter anyway.
>> >Additionally, compiler settings for building the kernel can be set
>> >COPTFLAGS in /etc/make.conf. Using anything other than -O or -O2 is
>> >not guaranteed to work. If you don't know what you are doing, do not
>> >COPTFLAGS and stick with the defaults that the build system
>>      Right.  -O3 might royally screw a kernel in particular. :-)
>>                                   Scott Bennett, Comm. ASMELG, CFIAG
>Thanks for add more useful info however would you mind elaborating a
>more because I do not understand the implications.

>should I have:
>in make.conf?
>Do I need anything else in make.conf?

>So far my draft make.conf has these entries:


>CFLAGS= -O2 -fno-strict-aliasing -pipe

>FORCE_MAKE_JOBS=        true

>Incidentally I am also puzzled because it appears necessary to use
>GENERIC as my starting point when the cpu is actually Intel Quad Core!!

>I presume this means that in drafting a kernconf I need to refer to;

>dns1# pwd
>dns1# ls -l
>total 44
>-rw-r--r--  1 root  wheel     13 Jun 20  2005 .cvsignore
>-rw-r--r--  1 root  wheel    482 Apr 15 04:14 DEFAULTS
>-rw-r--r--  1 root  wheel  11968 Apr 15 04:14 GENERIC
>-rw-r--r--  1 root  wheel    818 Apr 15 04:14 GENERIC.hints
>-rw-r--r--  1 root  wheel   1036 Apr 15 04:14 MAC
>-rw-r--r--  1 root  wheel    132 Apr 15 04:14 Makefile
>-rw-r--r--  1 root  wheel  20721 Apr 15 04:14 NOTES

>It would be great if some logical consistency could be introduced into
>conventions!!! It would really help those of us who know little and
make it a 
>trifle easier to climb the greasy pole of knowledge <chuckles>

It is logical.
You use i386 on old amd processors also.
The naming amd64 comes from the fact that AMD did come first with the 64
bit processor.
If Intel was the first it proberly would have a name like i386_64 or
something like that.

Nothing to worry about.
If your Intel proccessor has 64 bit support use the AMD64 version

It is just a name.

About the make.conf the use of nocona is ok but put a ? mark ofter
Do not ask me why, people told me it is better, if i understand
correctly It has someting to do about the choice the compiler has while
building, it could override the nocona setting if it is needed.
If i recall correct!!!!


I would ditch the CFLAGS, the normal setings ar the same as that line 

FORCE_MAKE_JOBS=        true

FORCE_MAKE_JOBS is also ok



No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.44/2282 - Release Date:
08/04/09 18:01:00
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to