History log of /freebsd/share/mk/bsd.cpu.mk (Results 226 – 250 of 323)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 44db0c5c 29-Mar-2003 David E. O'Brien <obrien@FreeBSD.org>

Reduce "code duplication" for AMD CPU's.


Revision tags: release/5.0.0_cvs, release/5.0.0, release/4.7.0_cvs
# 23bfdc2d 18-Sep-2002 John Baldwin <jhb@FreeBSD.org>

Whitespace-only indention fixups for revision 1.20. This lets the 1.20
diff actually be readable.


# f41fb58c 18-Sep-2002 John Baldwin <jhb@FreeBSD.org>

Oops, fix userland _CPUCFLAGS. Move adding of _CPUCFLAGS to bottom of
file after end of empty CPUTYPE else clause.


# eb28bc3e 18-Sep-2002 John Baldwin <jhb@FreeBSD.org>

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 buildker

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

show more ...


# fb3d2259 11-Sep-2002 David E. O'Brien <obrien@FreeBSD.org>

Add support for the AMD x86-64 Hammer platform.


# 0dafadb7 07-Sep-2002 Kris Kennaway <kris@FreeBSD.org>

Add support for ev67 and ev45 CPUTYPEs (new in gcc3)


# 8e4b67a2 07-Sep-2002 Maxime Henrion <mux@FreeBSD.org>

Update to use all the new CPU optimizations of GCC3.

Reviewed by: kris


Revision tags: release/4.6.2_cvs, release/4.6.2
# 32f8ca45 02-Aug-2002 Ruslan Ermilov <ru@FreeBSD.org>

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

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

show more ...


# 22e256fd 31-Jul-2002 John Baldwin <jhb@FreeBSD.org>

- 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

- 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.

show more ...


# 9bd85872 28-Jul-2002 John Baldwin <jhb@FreeBSD.org>

- 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 redunda

- 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).

show more ...


# 8605c6b2 28-Jul-2002 John Baldwin <jhb@FreeBSD.org>

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

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

show more ...


Revision tags: release/4.6.1, release/4.6.0_cvs
# 6e542f8c 13-Jun-2002 Maxim Sobolev <sobomax@FreeBSD.org>

In gcc 3.1 Pentium/MMX now has its own -march=XXX option.


# ce17d4f3 31-May-2002 Ruslan Ermilov <ru@FreeBSD.org>

Bootstrapping aid for those with Athlon upgrading from gcc 2.95.x.

Prodded by: gordon


# 22e5252f 15-May-2002 David E. O'Brien <obrien@FreeBSD.org>

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


# ab4448f3 11-May-2002 David E. O'Brien <obrien@FreeBSD.org>

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.


# 2c0b3c61 11-May-2002 David E. O'Brien <obrien@FreeBSD.org>

With GCC 3.1, we can now treat AMD Athlon and an Athlon.

Submitted by: Steven G. Kargl <kargl@troutmask.apl.washington.edu>


# a25fa515 10-May-2002 David E. O'Brien <obrien@FreeBSD.org>

Add the beginnings of Sparc64 support.


# cf80b5b5 18-Apr-2002 Ruslan Ermilov <ru@FreeBSD.org>

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


Revision tags: release/4.5.0_cvs, release/4.4.0_cvs, release/4.3.0_cvs, release/4.3.0
# d64b4068 21-Mar-2001 Kris Kennaway <kris@FreeBSD.org>

Pentium II's do not support SSE, that came in with the PIII

Submitted by: sf


# 5ca7924a 12-Mar-2001 Kris Kennaway <kris@FreeBSD.org>

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


# d6511a3c 10-Mar-2001 Maxim Sobolev <sobomax@FreeBSD.org>

AMD K6/K6-2/Duron/Athlon CPUs support MMX too.

Missed by: kris


# 181b6941 27-Feb-2001 Kris Kennaway <kris@FreeBSD.org>

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 fu

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

show more ...


# 62d90fb7 22-Feb-2001 Kris Kennaway <kris@FreeBSD.org>

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 us

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

show more ...


# 1e818404 02-Mar-2010 Warner Losh <imp@FreeBSD.org>

-mabi-calls and -msoft-float aren't needed either

Submitted by: jmallet@


# ab6b8778 02-Mar-2010 Warner Losh <imp@FreeBSD.org>

-mno-dsp hasn't been required for a while now.


12345678910>>...13