|
FreeBSD General Other questions regarding FreeBSD which do not fit in any of the categories below. |
|
Thread Tools | Display Modes |
|
|
|||
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.
__________________
Google Linux is a Green Horns Best Friend (GHBF). Windows = a 32 bit extensions to a 16 bit patch to an 8 bit operating system originally coded for a four bit processor written by 2-bit monopolistic software company founded by a .3-bit Harvard Drop out, who can't stand one respectable bit of competition. If I believe something to be immoral a will not keep quite and let my voice of annoyance be heard loud and clear. |
|
||||
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.
|
|
||||
Quote:
Hence, in the kernel config, the correct cpu entry to use is HAMMER, for all 64-bit x86 CPUs. Quote:
Quote:
Quote:
|
|
|||
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
__________________
Google Linux is a Green Horns Best Friend (GHBF). Windows = a 32 bit extensions to a 16 bit patch to an 8 bit operating system originally coded for a four bit processor written by 2-bit monopolistic software company founded by a .3-bit Harvard Drop out, who can't stand one respectable bit of competition. If I believe something to be immoral a will not keep quite and let my voice of annoyance be heard loud and clear. Last edited by FloridaBSD; 26th May 2008 at 04:53 AM. |
|
||||
Quote:
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. |
|
||||
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. |
|
||||
Quote:
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. |
|
||||
Quote:
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. |
|
||||
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
|
|
|||
Quote:
GROGAN I have only broken ports when using the -jx option. My system has never run better since specifying CPUTYPE in make.conf |
|
|||
-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.
|
|
||||
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. |
|
||||
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 |
|
||||
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. |
|
||||
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. Last edited by Grogan; 7th May 2008 at 06:55 AM. |
|
||||
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) |
|
||||
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. |
|
||||
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...1800DLV1C.html |
|
||||
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 Code:
# (AMD CPUs) opteron athlon64 athlon-mp athlon-xp athlon-4 # athlon-tbird athlon k8 k6-3 k6-2 k6 k5
__________________
The only dumb question is a question not asked. The only dumb answer is an answer not given. |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
FreeBSD 7.2 amd64 no sound | erim | FreeBSD General | 5 | 3rd June 2009 07:54 AM |
strange load problem on freebsd 7.0 amd64 | skynet_tech | FreeBSD General | 3 | 11th September 2008 09:49 PM |
Wine on FreeBSD 7.0 amd64 | BlueJayofEvil | FreeBSD Ports and Packages | 13 | 29th July 2008 12:22 AM |
jdk16 plugins on FreeBSD 7 AMD64 | ninjatux | FreeBSD General | 0 | 26th June 2008 07:55 PM |
FreeBSD 7.0 amd64 make installworld fails. | KernelPanic | FreeBSD Installation and Upgrading | 8 | 11th June 2008 04:34 PM |