Commit Graph

47 Commits

Author SHA1 Message Date
David E. O'Brien
efa2f9962d Rev 1.44 was a little over-zealous for FreeBSD/AMD64, trim. 2004-12-11 18:36:42 +00:00
John Baldwin
e1be1a8e8f No need to add I386_CPU to CFLAGS here for 80386 systems as they are no
longer supported.
2004-11-16 21:12:47 +00:00
David E. O'Brien
d41f6f569c Define "I386_CPU" if CPUTYPE is 'i386'. Userland bits can check for "I386_CPU"
to determine if they should select code paths suitable for the 80386 CPU.

Suggested by:	ru
2004-10-19 17:25:33 +00:00
David E. O'Brien
73c7393a9b Embellish the AMD64 sections a little. Including supporting 'nocona'. 2004-10-17 05:19:45 +00:00
David E. O'Brien
d5a538f65f + Simplify by treating the standard x86 CPU names as the CPUTYPE vs.
treating them as an alias.  Treat the shorthand versions as aliases.
+ Separate the x86 GCC CPU CFLAGS from the ICC CFLAGS.  This greatly
  simplifies the GCC section.  It also makes it more clear which CPU's
  have the same ICC CPU CFLAGS.
+ Remove redundancy in the alpha section.
+ Add forgotten ICC CPU CFLAGS for the mobile Intel CPU's added in rev. 1.42.
2004-10-17 05:08:29 +00:00
Dag-Erling Smørgrav
1af0547f8b Add support for Pentium M, Pentium 3M and Pentium 4M.
PR:		i386/72340
Submitted by:	Rong-En Fan <rafan@infor.org>
MFC after:	2 weeks
2004-10-07 09:56:48 +00:00
Olivier Houchard
fba25c542c Add CPUCFLAGS for the strongarm and xscale CPUs. 2004-09-23 22:59:31 +00:00
David E. O'Brien
55dfe3e212 Add more aliases for common CPUTYPE spellings 2004-08-11 21:51:27 +00:00
David E. O'Brien
fc2046e544 Consistently list _CPUCFLAGS. 2004-08-02 04:19:22 +00:00
Olivier Houchard
ac388bcd91 Define MACHINE_CPU for arm. 2004-05-14 13:34:15 +00:00
Doug Rabson
002d186bf0 Add ${CPUTYPE} support for crusoe processors (cribbed from Linux kernel
settings). Pretend that a crusoe is an i686 which doesn't like alignment
padding.
2004-04-05 09:55:50 +00:00
Marcel Moolenaar
1950e64cb2 Add a reference to the ia64 options to gcc. While here, sort the list. 2004-03-21 04:57:24 +00:00
Tom Rhodes
5a19f6d9d4 Fix some style bugs in previous commit.
Fix 'broken' ifdefs.
icc does not support profiling yet so remove unfinished code which was
supposed to help.

Submitted by:	netchild (original version)
Reviewed by:	ru
2004-03-14 01:29:05 +00:00
Tom Rhodes
06d6e4fcfe This are the build infrastructure changes to allow to use the
Intel C/C++ compiler (lang/icc) to build the kernel.

The icc CPUTYPE CFLAGS use icc v7 syntax, icc v8 moans about them, but
doesn't abort. They also produce CPU specific code (new instructions
of the CPU, not only CPU specific scheduling), so if you get coredumps
with signal 4 (SIGILL, illegal instruction) you've used the wrong
CPUTYPE.

Incarnations of this patch survive gcc compiles and my make universe.
I use it on my desktop.

To use it update share/mk, add
	/usr/local/intel/compiler70/ia32/bin	(icc v7, works)
or
	/usr/local/intel_cc_80/bin		(icc v8, doesn't work)
to your PATH, make sure you have a new kernel compile directory
(e.g. MYKERNEL_icc) and run
	CFLAGS="-O2 -ip" CC=icc make depend
	CFLAGS="-O2 -ip" CC=icc make
in it.

Don't compile with -ipo, the build infrastructure uses ld directly to
link the kernel and the modules, but -ipo needs the link step to be
performed with Intel's linker.

Problems with icc v8:
 - panic: npx0 cannot be emulated on an SMP system
 - UP: first start of /bin/sh results in a FP exception

Parts of this commit contains suggestions or submissions from
Marius Strobl <marius@alchemy.franken.de>.

Reviewed by:	silence on -arch
Submitted by:	netchild
2004-03-12 21:36:12 +00:00
Bruce Evans
d562095ead Fixed indentation of conditionals.
Submitted by:	Rostislav Krasny <rosti_bsd@yahoo.com>
2004-03-05 15:59:33 +00:00
Bruce Evans
c7fde57406 Fixed some style bugs (long lines). 2004-01-31 02:17:11 +00:00
John Baldwin
05d9236acf Drop -mcpu=pentiumpro from the default CPU flags for i386 as it doesn't
perform better than the default setting for most i386 CPUs.

Requested by:	bde
2004-01-30 19:51:26 +00:00
Ruslan Ermilov
2096f68ef2 Keep up with sys/conf/ changes. 2004-01-10 18:01:08 +00:00
Maxime Henrion
96f5595bf7 Since -march=pentium4 is supposed to be fixed with GCC 3.3, and
since people have been reporting success with it, re-enable the
pentium4 optimization.
2003-07-13 10:34:09 +00:00
Eric Anholt
b1aff8bff1 Change -march=pentium4 to -march=pentium3 when CPUTYPE==p4, because gcc 3.2 is
known to produce broken code with -march=pentium4.  Add a note explaining this.
This should be removed when we update to gcc 3.3 or the bug is otherwise fixed.

Approved by:	re
2003-05-22 16:56:46 +00:00
Peter Wemm
721b850f30 s/x86[-_]64/amd64/ for MACHINE_ARCH and MACHINE_CPU .ifdefs.
Noticed by:  ru
Approved by: re (amd64-specific low risk stuff)
2003-05-20 01:46:16 +00:00
David E. O'Brien
ae7906208d Add CPUTYPE support for "athlon-tbird", as GCC makes the distinction.
PR:		50801
Submitted by:	Glenn Johnson <glennpj@charter.net>
2003-04-14 17:36:29 +00:00
David E. O'Brien
7d40314e32 Default the userland to 486 capabilities. 2003-04-11 21:28:17 +00:00
David E. O'Brien
dde8112b23 Globally use -mieee in /usr/src for Alpha. 2003-03-29 03:14:24 +00:00
David E. O'Brien
44db0c5c9a Reduce "code duplication" for AMD CPU's. 2003-03-29 03:13:19 +00:00
John Baldwin
23bfdc2d66 Whitespace-only indention fixups for revision 1.20. This lets the 1.20
diff actually be readable.
2002-09-18 20:51:25 +00:00
John Baldwin
f41fb58cd1 Oops, fix userland _CPUCFLAGS. Move adding of _CPUCFLAGS to bottom of
file after end of empty CPUTYPE else clause.
2002-09-18 20:48:54 +00:00
John Baldwin
eb28bc3e98 For the default case of CPUTYPE not being set, don't define CPUTYPE to the
lowest value in order to get the right MACHINE_CPU values since setting
CPUTYPE can result in problems later in the buildkernel case.  Instead,
set MACHINE_CPU directly and leave CPUTYPE alone.

Tested by:	mbr
2002-09-18 20:44:46 +00:00
David E. O'Brien
fb3d225909 Add support for the AMD x86-64 Hammer platform. 2002-09-11 04:57:09 +00:00
Kris Kennaway
0dafadb731 Add support for ev67 and ev45 CPUTYPEs (new in gcc3) 2002-09-07 01:26:11 +00:00
Maxime Henrion
8e4b67a2a3 Update to use all the new CPU optimizations of GCC3.
Reviewed by:	kris
2002-09-07 01:15:29 +00:00
Ruslan Ermilov
32f8ca450d TARGET_CPUTYPE should exist solely in Makefile.inc1, similar to
TARGET_ARCH and TARGET.  This is problematic when one has the =
(unconditional) type of assigment for CPUTYPE in /etc/make.conf.
(This would override what was set on the command line to "make
buildworld".)

Add a (horrible) kludge to Makefile.inc1 to check the type of
assignment for CPUTYPE (only for those who attempts to set it to
a different value).  Fix an example make.conf.  Fix the kernel's
build-tools target (aicasm only at the moment) to catch up with
bsd.cpu.mk,v 1.15 (BOOTSTRAPPING replaced with NO_CPU_CFLAGS in
Makefile.inc1's BMAKE).

Reviewed by:	jhb
2002-08-02 18:04:22 +00:00
John Baldwin
22e256fded - Define NO_CPU_CFLAGS during BMAKE and TMAKE (and thus XMAKE) so that
bsd.cpu.mk doesn't have to worry about compilers other than the current
  version.
- Allow TARGET_CPUTYPE to override CPUTYPE in bsd.cpu.mk.
- Treat an empty CPUTYPE the same as an undefined CPUTYPE.
- For buildworld, buildkernel, etc., define TARGET_CPUTYPE to CPUTYPE for
  native builds and define it to be empty for cross-builds.
  TARGET_CPUTYPE is only defined if it is not already defined via the
  commandline or environment.
2002-07-31 03:56:03 +00:00
John Baldwin
9bd85872d1 - Fixup whitespace after previous commit.
- To minimize whitespace changes, remove a test that didn't define
  _CPUCFLAGS if both NO_CPU_CFLAGS and NO_CPU_COPTFLAGS were defined
  since it is redundant (we don't use _CPUCFLAGS if those are defined).
2002-07-27 22:15:42 +00:00
John Baldwin
8605c6b2ad If there is not a CPUTYPE defined by default, then allow for _CPUCFLAGS
to tune for more advanced processors while still supporting the minimum
processor in an architecture.  We can do this with the '-mtune=' option
to gcc for alpha, sparc64, and powerpc and with the mis-named '-mcpu='
option for i386.

This defaults to tuning i386 builds for i686 machines though not using
any instructions that aren't found on an 80386.  For alpha it defaults
to tuning for an EV5.

Approved by:	peter
Peril sensitive sunglasses borrowed from:	peter
2002-07-27 22:04:05 +00:00
Maxim Sobolev
6e542f8c06 In gcc 3.1 Pentium/MMX now has its own -march=XXX option. 2002-06-13 08:35:36 +00:00
Ruslan Ermilov
ce17d4f3d3 Bootstrapping aid for those with Athlon upgrading from gcc 2.95.x.
Prodded by:	gordon
2002-05-31 12:50:24 +00:00
David E. O'Brien
22e5252fed Default Alpha compiles to ev5.
EV5 binaries will run on EV4[5], but the timing assumptions do pessimize
running on EV4[5].

Tested by:	ticso
2002-05-15 18:16:43 +00:00
David E. O'Brien
ab4448f3e4 Add pointers to GCC's allowable values for -march, and restore structure
of rev 1.7 until someone can sit down and think thru all the GCC 3.1
related changes.
2002-05-11 20:18:54 +00:00
David E. O'Brien
2c0b3c611a With GCC 3.1, we can now treat AMD Athlon and an Athlon.
Submitted by:	Steven G. Kargl <kargl@troutmask.apl.washington.edu>
2002-05-11 20:05:17 +00:00
David E. O'Brien
a25fa515ee Add the beginnings of Sparc64 support. 2002-05-10 01:31:40 +00:00
Ruslan Ermilov
cf80b5b504 Optimize for i486 better (-m486 is just another deprecated
synonym for -mcpu=i486).

PR:		i386/37212
Submitted by:	Matthias Andree <matthias.andree@web.de>
MFC after:	3 days
2002-04-18 09:37:15 +00:00
Kris Kennaway
d64b406847 Pentium II's do not support SSE, that came in with the PIII
Submitted by:	sf
2001-03-21 08:29:39 +00:00
Kris Kennaway
5ca7924a91 Use CPUTYPE to add appropriate compiler flags to COPTFLAGS for kernel
builds.  This may be disabled using the NO_CPU_COPTFLAGS variable.

Reviewed by:	arch
2001-03-12 07:47:09 +00:00
Maxim Sobolev
d6511a3c8d AMD K6/K6-2/Duron/Athlon CPUs support MMX too.
Missed by:	kris
2001-03-10 11:49:05 +00:00
Kris Kennaway
181b6941c7 Add definitions and support for the AMD k6-2, Pentium MMX (i586/MMX),
and Pentium II, III and IV processors (p2, p3, p4), as well as 'mmx' and
'3dnow' MACHINE_CPU tags as appropriate.  In the near future this will
be used to control various ports which have MMX/3dNow optimizations,
instead of the ad-hoc methods currently used.

Reviewed by:    peter
2001-02-27 11:21:47 +00:00
Kris Kennaway
62d90fb793 Overhaul the MACHINE_CPU behaviour:
* Rip out MACHINE_CPU stuff from sys.mk and include a new <bsd.cpu.mk>
  after we pull in /etc/make.conf.  We need to do it afterwards so we can
  react to the user setting of the:

* CPUTYPE variable, which contains the CPU type which the user wants to
  optimize for.  For example, if you want your binaries to only run on an
  i686-class machine (or higher), set this to i686.  If you want to support
  running binaries on a variety of CPU generations, set this to the lowest
  common denominator.  Supported values are listed in make.conf.

* bsd.cpu.mk does the expansion of CPUTYPE into MACHINE_CPU using the
  (hopefully) correct unordered list of CPU types which should be used on
  that CPU.  For example, an AMD k6 CPU wants any of the following:
    k6 k5 i586 i486 i386
  This is still an unordered list so the client makefile logic is simple -
  client makefiles need to test for the various elements of the set in
  decreasing order of priority using ${MACHINE_CPU:M<foo>}, as before.
  The various MACHINE_CPU lists are believed to be correct, but should be
  checked.

* If NO_CPU_CFLAGS is not defined, add relevant gcc compiler optimization
  settings by default (e.g. -karch=k6 for CPUTYPE=k6, etc).  Release
  builders and developers of third-party software need to make sure not to
  enable CPU-specific optimization when generating code intended to be
  portable.  We probably need to move to an /etc/world.conf to allow the
  optimization stuff to be applied separately to world/kernel and external
  compilations, but it's not any worse a problem than it was before.

* Add coverage for the ia64/itanium MACHINE_ARCH/CPUTYPE.

* Add CPUTYPE support for all of the CPU types supported by FreeBSD and gcc
  (only i386, alpha and ia64 first, since those are the minimally-working
  ports.  Other architecture porters, please feel free to add the relevant
  gunk for your platform).

Reviewed by:    jhb, obrien
2001-02-22 11:14:25 +00:00