FreeBSD amd64 arch Cpu type

[Grogan]

Hello

I couldn't help but learn that people from the bsdforums are moving here, so I'll re-post my question.

I have an Intel Core 2 Quad Q6600 CPU and was wondering if there was a better cpu type than "Hammer" to use for this processor? Is it even possible to choose others for this arch? I figured that was probably the best target, (hence, the default for amd64), and it seems to detect my CPU's features correctly but is there something I could choose that's more optimal? I configured and built my kernel and it seems to run just fine but there's always that nagging doubt that I could have used something better :)

The NOTES only shows HAMMER

I thought I'd look through some of the cpu related stuff under /usr/src/sys/amd64 and found this. (cputypes.h)


/*
* Classes of processor.
*/
#define CPUCLASS_X86 0 /* X86 */
#define CPUCLASS_K8 1 /* K8 AMD64 class */
/*

* Kinds of processor.
*/
#define CPU_X86 0 /* Intel */
#define CPU_CLAWHAMMER 1 /* AMD Clawhammer */
#define CPU_SLEDGEHAMMER 2 /* AMD Sledgehammer */

Would I be better off defining X86 instead (and still obviously have a 64 bit kernel)

This is what I get from dmesg (looks ok to me... detected as a K8-class)

CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2400.01-MHz K8-class CPU)
Origin = "GenuineIntel" Id = 0x6fb Stepping = 11
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,P GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SS E,SSE2,SS,HTT,TM,PBE>
Features2=0xe3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR, PDCM>
AMD Features=0x20100800<SYSCALL,NX,LM>
AMD Features2=0x1<LAHF>
Cores per package: 4

[FloridaBSD]

The Intel Core two Duo processors are considered as members of the x86_64 processor family, which fiI am not the least bit wrong means that the iso images you used to burn your installation media wern't he correct ones.

[Grogan]

Thanks for the reply, but that's not true. "amd64" refers to the arch and is generally synonymous with x86_64 (in fact x86_64 is the arch according to the compiler) The other 64 bit download option, ia64, is a completely different arch for Itanium-like processors. That would definitely not run.

[phoenix]

I have an Intel Core 2 Quad Q6600 CPU and was wondering if there was a better cpu type than "Hammer" to use for this processor?

AMD released their 64-bit CPU extensions first, and were the first supported by FreeBSD. Hence, the FreeBSD port to 64-bit x86 is called "amd64" and the CPU class in the kernel is called "HAMMER". AMD's Hammer class of CPUs were the first ones to support 64-bit (Sledgehammer, Clawhammer, and one other hammer).

Hence, in the kernel config, the correct cpu entry to use is HAMMER, for all 64-bit x86 CPUs.

Is it even possible to choose others for this arch?

No.

I configured and built my kernel and it seems to run just fine but there's always that nagging doubt that I could have used something better :)

Well, you could have used a real amd64 CPU from AMD. :)

This is what I get from dmesg (looks ok to me... detected as a K8-class)

K8 was the name given to the Hammer family of CPUs by AMD. It followed the K7. Just as every Intel CPU since the PentiumPro has been an "i686-class" CPU, so has every CPU from AMD since the Athlon64 been a "K8-class" CPU. Intel and AMD CPUs running in 64-bit mode are considered "K8-class" while Intel and AMD CPUs running in 32-bit mode are considered "i686-class".

[Grogan]

Thanks, that confirms much of what I thought. I just didn't know for sure if there were other CPU types available. (Note that I'm coming from Linux where there are individual definitions for various processors. It's still much the same though, the kernel will still detect the CPU's features properly and will still run on a compatible one, though perhaps not optimally)

This is a Hell of a nice setup.

[FloridaBSD]

Does this mean that the AMD Atlon X2 Duel Core 5600+ processor in my Pavillion a6230n Desktop Is acyurally not based uopon a true sixty-four bit Processor, but instead A 32 bit chip masquerading as a 6bit chip

[Grogan]

Essentially correct, the x86_64 chips (AMD64 and later copied by Intel who calls it EM64T) are really x86 processors with 64 bit extensions (additional registers and stuff activated by a 64 bit operating system kernel). They can run both 32 bit and 64 bit code natively. That doesn't mean anything inferior... it's the best of both worlds. Intel's idea of IA64 didn't really catch on, it was too incompatible. Microsoft thumbed their noses at it because too much of their rubbish would have had to be rewritten from the ground up lol

[phoenix]

Thanks, that confirms much of what I thought. I just didn't know for sure if there were other CPU types available. (Note that I'm coming from Linux where there are individual definitions for various processors.

The Kernel CPU type is for the architecture of the machine (i386, hammer, ia64, ppc, etc). This is the broad, general architecture (instruction set) of the system. Internally, the individual source files will check for various functions of the underlying hardware and use what's best. FreeBSD tries to keep things simple, in that it gives you classes of features/drivers to enable, and then auto-detects the specifics as needed (compare ATA subsystems - FreeBSD: device ata vs. Linux: several pages of individual chipsets to select from)

You can set the exact CPU type in the machine via /etc/make.conf and that will enable different features in the software you install via the ports tree or when compiling the world or kernel. See /usr/share/examples/etc/make.conf for all the details. This sets all the gcc options like -m -cpu and so forth.

[phoenix]

Does this mean rthat the AMD Atlon X2 Duel Core 5600+ processor in my Pavillion a6230n Desktop Is acyurally not based uopon a true sixty-four bit Processor, but instead A 32 bit chip masquerading as a 6bit chip

64-bit x86 CPUs are not "designed from the ground up" to be 16-bit, 32-bit, or 64-bit (the 80286 was just a 16-bit evolution of the 8-bit 8086, the 80386 was just a 32-bit evolution of the 16-bit 80286, and the athlon64 is just a 64-bit evolution of the 32-bit 80386). They are just extensions of earlier designs to support new 64-bit features. They are an evolutionary step in the lifetime of the x86 architecture. However, that's not to say they aren't true 64-bit CPUs, as they are; it just depends on the OS you install.

If you install a 32-bit OS on your amd64 CPU, you get a souped-up 32-bit CPU.

If you install a 64-bit OS on your amd64 CPU, you get a 64-bit CPU, with all the advanced features that come with it.

[Grogan]

You can set the exact CPU type in the machine via /etc/make.conf and that will enable different features in the software you install via the ports tree or when compiling the world or kernel. See /usr/share/examples/etc/make.conf for all the details. This sets all the gcc options like -m -cpu and so forth.

I do this in make.conf:

For kernel:
COPTFLAGS=-O2 -march=nocona

That's safe enough, because the kernel build system turns off potentially harmful instructions (e.g. -mno-sse2 -mno-sse3 -mno-mmx etc.) that would be enabled by -march.

That's just optimizing the execution of the kernel functions themselves though.

For general software:
CFLAGS=-O2 -mtune=nocona

That's safe enough to enable globally. -mtune just tunes the scheduling and stuff for the specified cpu and doesn't break anything.

nocona is about the closest thing to correct that gcc 4.2.x will do for my CPU. Once gcc 4.3.x is a bit more mature and usable (and projects catch up with it), there's a core2 cpu type.

[phoenix]

Don't do that. Leave CFLAGS alone. You have removed a whole list of defaults that may lead to breakage down the line.

Set CPUTYPE in /etc/make.conf and let the make system fill in the rest based on that. CPUTYPE sets -march, -mtune, and a bunch of others.

[Grogan]

Hmm, OK, thanks. I'll stop doing that (Been doing CFLAGS in make.conf since FreeBSD 5 though). I would have thought it just appended to the compile commands. I've never done a build world though, but it's never caused me a problem with any of the ports that I use.

I wouldn't want to do CPUTYPE=nocona though, because that will blindly enable things like SSE2 and SSE3 etc. which does break builds, or worse, subtly breaks the results. CPUTYPE seems to do -march

[phoenix]

CPUTYPE sets various flags for port and world compiles. It doesn't enable things like SSE for kernel compiles, though. The build system is smart enough to know what is safe for the kernel and what is safe for the world.

Until you set CFLAGS, that is. Then things can go haywire. If you use CFLAGS=whatever, then you are replacing the CFLAGS set in the build system. If you use CFLAGS+=whatever, then you append to the end of the CFLAGS line, again overriding anything set previously. If you use CFLAGS="whatever ${CFLAGS}" then you add your option in front of the defaults, and the defaults override your settings. Things can get pretty hairy. :)

And the default CFLAGS do change overtime (for instance, -O2 is the default now).

Better to set CPUTYPE, don't set CFLAGS, and just let the build system do its job. :D

[Grogan]

Yep, I agree there's no problem with using -march for the kernel (as stated, the kernel build system disables such instructions with with -mno in every compile command, including the modules that get built for everything you disable in the main kernel image) but that's not the case with ports.

In my sillier days, I used to do -march=pentium4 for everything I compiled in Linux until I learned that SSE2 subtly breaks stuff. It's not something you can put your finger on either. One time I had a problem with certain gtk+ dialogs intermitently crashing the X server. Some chooser dialogs, Gimp options, the file manager in XFCE. The cause was GTK+ being compiled with -march=pentium4, specifically the use of SSE2. That caused me a lot of aggravation. I was attacking the problem as if it was something to do with X. As if it was something to do with the Radeon driver. Everything but Grogan and his stupid compile flags :-)

I've also subtly broken some functions in programs that way too. The rest of the program works fine, except for a few features.

That said, I decided to do it anyway lol

CPUTYPE=nocona in make.conf. If anything breaks, I'll fix it and not do it anymore. I just want to see for myself how things have progressed. Things may not miscompile anymore, gcc is smarter than it used to be now too.

I took out the other stuff.

I wanted to rebuild my kernel again tonight anyways, to try that SCHED_ULE which is purported to be a better scheduler for SMP. So far it's doing quite well (watching top while the system is under stress) and staying snappy.

[pcfxer]

Essentially correct, the x86_64 chips (AMD64 and later copied by Intel who calls it EM64T) are really x86 processors with 64 bit extensions (additional registers and stuff activated by a 64 bit operating system kernel). They can run both 32 bit and 64 bit code natively. That doesn't mean anything inferior... it's the best of both worlds. Intel's idea of IA64 didn't really catch on, it was too incompatible. Microsoft thumbed their noses at it because too much of their rubbish would have had to be rewritten from the ground up lol

...and then made efficient and secure-WHAT A CONCEPT!>!>!

GROGAN I have only broken ports when using the -jx option. My system has never run better since specifying CPUTYPE in make.conf

[DrJ]

GROGAN I have only broken ports when using the -jx option.
-jx works fine for building world, but not for the kernel or ports. Making ports suitable for parallel compilation is happening, but is not there yet.

[Grogan]

Thanks guys, coincidently I just did a buildworld tonight, with CPUTYPE=nocona and it passed -march in the compile commands. So far, everything seems to be good.

First time I did one and it wasn't a big job at all. It didn't even take an hour, even without -j. (I chickened out on that because it said to avoid using it in the notes). Next time I'll try -j5.

It'll be good if they ever make ports parallel build safe... it's a drag when you're waiting on stuff to finish. (though there's nothing stopping me from doing other non-ports build jobs at the same time)

[Grogan]

Well, even though ports doesn't support -j, there's nothing stopping me from getting work done. I've been redoing KDE from ports tonight, and after I got libs and base and stuff down, I've been building 3 ports at the same time to get all the rest of the KDE components done. And still plenty of CPU cycles free for surfing the web and listening to tunes and stuff at the same time :-)

I was worried that maybe some environment variables would collide or something, but since they are separate virtual terminals (rxvt) that can't really happen.

Really good scheduling here... I can hardly tell I'm compiling. I think this is where FreeBSD kicks ass.

[Calderon]

Can i use CPUTYPE Athlon or Athlon-xp, as i´m having duron 1800Mhz applebred?

Some say that the only difference between athlon and that duron is cache...

If i can´t, what should i use?

Thanks.

http://www.cpu-world.com/CPUs/K7/AMD-Duron%201800%20-%20DHD1800DLV1C.html

[robbak]

I think that the only CPUTYPE for amd64 at the moment is athlon64.

OH, and please don't threadjack. If you have a question, ask it with a new thread (after searching, of course). Please do not simply tack it onto the end of someone else's thread.

Doubly important if the thread does not apply to your CPU - that is not a 64 bit cpu!!!

A slightly older /usr/share/examples/etc/make.conf lists these as the CPUTYPES for AMD CPUs
# (AMD CPUs) opteron athlon64 athlon-mp athlon-xp athlon-4
# athlon-tbird athlon k8 k6-3 k6-2 k6 k5

Take your pick.

[Grogan]

I would use CPUTYPE=athlon in make.conf for that CPU. For gcc 4.2.x, these are your choices for x86/x86_64

http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options

If building kernel, you haven't got a lot of choice for the i386 arch. For that one, in the kernel config you'd have to use:

cpu I686_CPU

I don't mean to go against the rules here (I agree with that in general), but I don't mind people asking related questions in my threads. (In fact I don't consider it "my thread", I only started it). I spend a lot of time in forums, and sometimes in a thread something will inspire a question and it is practical to ask it there. It isn't necessarily thread hijacking. I believe this to be one of them. The topic did change since my original question... we got into CPUTYPE in make.conf and other make options.

[Calderon]

Oh, im very sorry. I have been notified on other forums about making new topics (after searching etc. think the line is a bit fuzzy anyway) so im a bit afraid. But glad to know that here it isn´t so. ill leave this one alone for now.

EDIT: Thanks Grogan

[Alspector]

Just wanted to say thanks for all of the helpful information that has been posted in this thread. It really helped me tie together a bunch of the research I was doing before compiling my custom kernel and kept me from having to make posts to ask questions. :)

[vermaden]

This is best source if you are looking for basic CPUTYPE / CFLAGS:
http://gentoo-wiki.com/Safe_Cflags

[Weaseal]

This is best source if you are looking for basic CPUTYPE / CFLAGS:
http://gentoo-wiki.com/Safe_CflagsI was looking at my proc on there... AMD Turion 64... Why do you think they don't recommend -fomit-frame-pointer for 64bit but do for 32bit? Curious...

[vermaden]

from gcc.gnu.org manual:
-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.

-fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines.

On some machines, such as the VAX, this flag has no effect, because the standard calling sequence automatically handles the frame pointer and nothing is saved by pretending it doesn't exist. The machine-description macro FRAME_POINTER_REQUIRED controls whether a target machine supports this flag. See Register Usage.

Enabled at levels -O, -O2, -O3, -Os.

rest: http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Optimize-Options.html#Optimize-Options

Also -fomit-frame-pointer does good things on C code, but it may break C++ code, so use only for C.

[Grogan]

It's not that they don't recommend -fomit-frame-pointer for x86_64, it's just that you don't need to specify it because -Oanything enables it. (and apparently doesn't for x86, so they show that you can explicitly do so). Also, just because they are showing something as "safe" for gentoo, doesn't mean there is much point in doing it.

[vermaden]

Also, just because they are showing something as "safe" for gentoo, doesn't mean there is much point in doing it.
GCC and Linux kernel is the same in all Linux distribution so Gentoo is no point here, GCC is also on FreeBSD and other UNIX systems, so this flag also works there.

[robbak]

I wouldn't go too far with that point. Yes, it is the same GCC, but some of gcc's optimizations have on occasion assume some linuxisims.

Optimizations that work on the linux kernel or gnu code may still produce broken code on the BSD tree.
That is still a useful list, but don't take it as gospel.

[vermaden]

Optimizations that work on the linux kernel or gnu code may still produce broken code on the BSD tree.

I would not said that if I would not test them first.

I always used -fomit-frame-pointer for all Ports and they NEVER been broken, it just disables debuging and you get one register more for other things.

[BSDfan666]

The frame pointer actually has additional purposes, honesty, you should reconsider using all those optimizations, some levels of optimizations may be dangerous.

In the kernel, inline assembly is often used.. it may even rely on the stack pointer being present.

Unless you have a deep intimate knowledge of compiler mechanics and kernel internals.. stop recommending such things vermaden.

[vermaden]

In the kernel, inline assembly is often used.. it may even rely on the stack pointer being present.
Tell me where I was saying to use it for kernel ...

I would be GLAD to see that quote.

stop recommending such things vermaden.
I know what I am doing.