On Thu, Jan 06, 2005 at 03:42:02AM -0500, Felix Miata wrote: > Matthew Miller wrote: > > On Wed, Jan 05, 2005 at 07:09:03PM +0200, Stuart Lamble wrote: > > > > When I execute rpmbuild -bp --target=ARCH kernel-2.6.spec, what should I be > > > substituting for the ARCH bit. > > > I have a P2 machine. I also have a P4 machine. > > > Is there any difference between using i586 or i686? > > > Both of these are i686. Only original Pentium (and Pentium MMX) are i586. > > Pentium Pro and onward are i686. > > Your "only" is inappropriate. K6 & K6/2 are also i586. See also > https://bugzilla.mozilla.org/show_bug.cgi?id=233815 > -- The simple answer is to see what the install tool selected for you in the past and build another one just like the other one (see uname). For most of us "uname -m" returns the answer we need. The more interesting answer will be found in the source for the kernel and in the flags passed to the compiler. In this case --target=ARCH is a Makefile thing and you have to look under a lot of rocks to sort it out. Try some things and keep notes. I have found the README files full of clues but not answers. The compiler flags are interesting. From the gcc man page. "While picking a specific cpu-type will schedule things appropri- ately for that particular chip, the compiler will not generate any code that does not run on the i386 without the -march=cpu-type option being used. i586 is equivalent to pentium and i686 is equivalent to pentiumpro. k6 and athlon are the AMD chips as opposed to the Intel ones." Lots more gcc special flags to pay attention to. In this case it can be important to see how the makefile is passing the flag. The kernel Makefile(s) will link different object files and call the compiler with different flags depending on what you specify. Contrary to common expectations the kernel does not do very many things that justify fancy flags. With the exception of bcopy() and bzero() most code is simple integer or pointer arithmetic stuff common to all processors. The exceptions are often hand coded assembler and often this code is tested for and the fast path is hooked up at boot time so it is a don't care for us mortals. For the geeks out there instruction scheduling and optimizations can also be done in the assembler. Those that want to go fast need to look at all the layers (same for those doing debugging). Depends on the development tool set being used. The above bugzilla involves Firefox... Unlike the kernel, FANCY compile time and register use optimizations can yield very big measures of improvement for user space applications where 90+% of the time is spent. In a large package like the kernel each .o, .ko .a and a.out need not be generated with exactly the same flags. -- T o m M i t c h e l l spam unwanted email. SPAM, good eats, and a trademark of Hormel Foods.
