On Wed, 21 Feb 2007 13:58:47 -0800 Steven Hillis wrote:
Good morning[1] Steve!
> Apologies for the confusion, I gave you working tags
from memory, not my
> make.conf file (i've been jockeying back and forth
between a FreeBSD and a
> gentoo box, and use the same tags on them both, -mcpu
on gentoo, -mtune on
> freebsd).
You had me going there for a moment - actually for quite a
while.  I
sat at my computer for hours on end trying to figure out why
the heck
those flags worked on you machine an not on mine. I don't
think you need
to apologise for anything though. I read a lot of stuff and
bookmarked a
lot of new pages that may prove helpful at some time in the
future.
Mistakes are quite normal for human beings and this one made
me do
somthing productive for a change.
Back to the issue:
I'm guessing you know that -mcpu and -mtune do *very*
different things.
> FreeBSD sparc64 only supports ultrasparc and
ultrasparcII cpus, so far as I
> know, so -mcpu=ultrasparc is superfluous. I in fact
have -mtune=ultrasparc,
> since they likely use the v9 standard for FreeBSD since
they seem to be
> attempting Ultrasparc III support. Again, I'm sorry
about my bad memory.
> -mcpu=ultrasparc and -m64 should both be useless
options under Sparc64, as
> far as I can tell.
Since I wasn't doing anthing special last night I compiled
a new
world and stuffed the output info a file instead of stdout.
I greped
though that and didn't find any -mcpu flags in that. So it
is quite
likely that the whole thing is being compiled as v7 code -
which BTW
doesn't mean that it really has to run on an SS20. I'm not
sure if this
really is the case but it is quite likely that there is no
mcpu set.
During my research I have found several sites claiming that
usually
there is not mcpu set - on most operating systems. NetBSD
was often used
as an example. Ok, unlike FreeBSD that also has a branch for
SPARC32,
but especially in *that* case you'd think that this flag
*should* be set
in the SPARC64 branch.
All of these sites I found didn't actually go into compiling
the OS
itself but usually went for some apps running under the OS,
usually
OpenSSL or OpenSSH.
Creating 64bit code (the -m64 flag) should *not* be set
globally (IMHO).
This really only sets the pointer and long to 64 bits. It
could cause
problems with some software that rely on a long with 32 bits
only (if
there is any out there). -m64 isn't faster per definition.
Only programs
using a lot of pointers (like chess programs) may profit
from this
setting. AFAIK even under Solaris the default is -m32. Is
many cases -m64
is slower than -m32.
> My actual make.conf file is as follows:
> CFLAGS=-O2 -pipe -mtune=ultrasparc -mvis -mapp-regs
-fomit-frame-pointer
> -ffast-math -fweb -frename-registers
> COPTFLAGS=-O2 -pipe -mtune=ultrasparc -mvis -mapp-regs
-fomit-frame-pointer
> -ffast-math -fweb -frename-registers
I must admit that I'd be a bit to chicken to enable all of
those. The
ffast-math can cause some "strange" results in
some programs and if it
does it may take ages to track down where the problem comes
from.
Have you had any problems with these at all? I believe that
buildworld
compiles with these settings but have you ever had any
problems with
other software (compiling and/or running)?
> NO_MODULES=YES
> NO_PROFILE=YES
Why? [2]
> .if (!empty(.CURDIR:M/usr/src*) ||
!empty(.CURDIR:M/usr/obj*)) &&
> !defined(NOCCACHE)
> CC=/usr/local/libexec/ccache/world-cc
> CXX=/usr/local/libexec/ccache/world-c++
> .endif
I can read this script, but I don't quite see what it does
for you. Have
you replaced the default cc with something else like a newer
gcc?
> Those flags compile without a hitch. Again, Sparc64 is
only for ultrasparc
> CPUs, so that's not really needed.
> The question is (this is aimed at Marius, et al), why
does setting the -mcpu
> flag unset the __sparc64__ definition in so many
places? This is what your
> errors came from, there are about 20 files that will do
that.
Setting the mcpu flag at all will actually cause that. So it
doesn't
matter if I set it so ultrasparc or v9, this effect kicks in
all the
time.
Regards
Chris
[1] At least here in Germany it is.
[2] Trying to learn something here, not meant critically.
_______________________________________________
freebsd-sparc64 freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc
64
To unsubscribe, send any mail to
"freebsd-sparc64-unsubscribefreebsd.org"
|
