I am just asking myself what the optimum architecture specific optimizations are that I would have to choose for my Sparc's CFLAGS. (an Ultra 5 with a 400MHz Sparc IIi)

Have to say that I found make.conf's comments a bit irritating and even after consulting gcc man/info pages that didn't make things perfectly clear. Maybe it's just me but...

1.) -mcpu vs. -mtune? (which one or both?)

regarding -mcpu/-mtune make.conf says:
#-mcpu=<cpu-type> means optimize code for the particular type of CPU without
# breaking compatibility with other CPUs.
# -mtune=<cpu-type> set the instruction scheduling parameters for machine, but
# do not set the instruction set or register set.

So this seems to be quite comparable to '-mcpu' and '-march' on x86. Then I'd normally say choose '-mtune' in favour of '-mcpu' here. Right?
OTOH the comment seems to state that '-mtune' does less optimizations than '-mcpu'.

Well, so first of all this doesn't make it totally clear for the average joe doe which side of this list one should add to CFLAGS - is it 'v9' or 'ultrasparc'? And where is the difference?

mmh, ok, after having a look into the man page I would say that one can either add 'v9' ("inferior") or 'ultrasparc' (preferable because of more specific optimizations) to '-mcpu' or '-mtune' but at least for '-mtune' only 'ultrasparc' makes sense.

3.) CHOST (change it or leave it as it is?)

Do I have to or can I change CHOST? The comment above CHOSTS seems to say that but doesn't make it totally clear.

So should I change the default:
CHOST="sparc-unknown-linux-gnu"
to
CHOST="sparc-Sun4u-linux-gnu"?

-mtune is more for when you want to make a binary that'll work across multiple CPU types, but run best on a given one. -mcpu would be more optimized, but not backwards compatible.

the difference between ultrasparc and v9? I'm not entirely sure myself. Sometimes v9 can cause programs to believe they can compile in 64 bit (which currently cannot be done on Gentoo). There's also the fact that v9 could refer to actual Sun CPUs, where ultrasparc is actually a clone sparc64 chip (made by toshiba or fujitsu or ?)

As for CHOST, in an ideal world yes you could change it. However right now if you do change it, it can and will cause some ebuilds to break or install incorrectly, though you won't get any indication of this until something else down the like breaks (one example of this is the gcc-sparc64 package).

I am not sure what the differences between -mcpu=ultrasparc and
-mcpu=v9 are, but I know they are not equivalent. The compiler does not
generate the same code for one as for the other.

Since sparc-v9 is the name of an architecture standard, I would expect that
if you specify -mcpu=v9, the resulting code should run on any processor that
implements the standard. If so, then -mcpu=ultrasparc should optimize for
a superset of that standard. (Ultrasparc is the name of an implementation
of the sparc-v9 architecture.)

Check out http://www.sparc.com if you want copies of the architecture manual
and descriptions of how the implementations differ.

Example: I have an Ultra-2 is a sparc-v9 with ultrasparc-II processors manufactured
by TI, thus:

Hi everyone.
Ok, thanks for your answers. At least it seems that I am not the only one who is a bit puzzled by these options (or rather the lack of clear documentation) even though I really wouldn't consider myself a complete newbie to that topic.

I just found a very interesting and very valuable link regarding this topic that makes things much more clear:
SPARC Optimizations With GCC best of all - this article is just a few days old!

Weeve there might probably be some information in this article that might make a nice addition to the existing comments in make.conf ...?

Some favourite random quotes:
"So while -mtune is the same on both x86 and SPARC (creates backward compatible tuned binaries), -mcpu creates CPU-specific binaries (and not backward compatible) for SPARC, and -march does the same for x86."

"[...] the performance optimizations discussed can have a potentially huge impact on performance on SPARC systems, much more dramatically than comparable optimizations on x86 systems.

As such, adding -mcpu options for compilation is a good idea for systems that support V8 or higher."

=> to sum up using e.g. "-mcpu=ultrasparc" seems to be the way to go! So I will stay with my current setting of "-mcpu=ultrasparc -O3 -pipe -fomit-frame-pointer -fstack-protector" for my Ultra 5.

-fomit-frame-pointer doesn't keep the so called "frame pointer" in a register at least for the functions that don't need it. This saves the operation(s) itself and more important it also frees an additional register which would normally be used to store the frame pointer. Using this option can therefore (sometimes vastly) improve speed of applications.

BTW I just checked man gcc and saw that it says it is already "enabled at levels -O, -O2, -O3, -Os" - which must be relatively new.
Some years ago (at least probably around gcc older than 3.1/3.0 or so) you always had to explicitly add it.
So you probably can omit that one because it is redundant.

-fstack-protector enables ProPolice or stack-smashing protector. A gcc extension developed by IBM which can protect you from (not all but most) stack smashing attacks. (=common exploits/security holes...)

While this is in general a very nice and good thing, currently don't use that (at least on sparc) if you don't know exactly what you are doing... [1]

Hope that helps.
----
[1] you have to manually emerge a current gcc (>= 3.3.2-r5) to avoid multiple bugs in a few packages. I am just about to set up a sparc system with gcc-3.3.3 and SSP enabled which so far seems to work fine.

I am not sure what the differences between -mcpu=ultrasparc and-mcpu=v9 are, but I know they are not equivalent.

Here is my understanding:

Since the sparc architecture is an open architecture (anyone willing to pay for the license may design a chip using the Scalable Processor ARChitecture) you might find each vendor's chip is slightly different. As long as they adhere to the V9 specs, these different chips will all run the same code (same basic instructions).

However, a vendor like SUN might add additional functionality to its particular chip which would differentiate it from another manufacturer such as Fujitsu (actually, SUN does not do its own manufacturing, it contracts TI to build its chips but does do the design in house - if my memory serves me correctly). SUN's version of the V9 architecture is labelled "UltraSparc".

So: the -mcpu=v9 allows one to build code which runs on all V9 compliant chips while -mcpu=ultrasparc choses a particular implementation of the V9 architecture such as the UltraSparc...

Besides cracking open the box....is there a way to find out what processor you have? My Ultra2 I got in, had root with no password...so, I can get into Solaris. Is there a command that will print out the processor stats?
Also from this thread...I'm seeing that -mcpu is the best way to go if you know the specifc processor you have.

Will this have any effect if you are wanting to netboot a different Sun box? ( I picked up a couple of sparcstations and will probably install/run them this way).....

Thanks for helping with noob questions here...very new to Sparc.

cayenne_________________Light travels faster than sound. This is why some people appear bright until you hear them speak.........

Besides cracking open the box....is there a way to find out what processor you have? My Ultra2 I got in, had root with no password...so, I can get into Solaris. Is there a command that will print out the processor stats?

I have never personally seen any processor inside an Ultra-class machine which didn't run a geniune SUN processor. There is the possibility someone did manufacture a replacement but I have never seen one. Anyhow, you are completely safe if you use "-mcpu=v9" and are reasonably safe with "-mcpu=ultrasparc". Once you confirm you have a SUN produced chip, the "ultrasparc" spec is proper (but in reality may not produce a noticible difference).

Hmmmm... Solaris... It's been a while. The proc system is much different from the implementaion in Linux and not as useful (imho). You could try "dmesg | less" and parse the output. I do recall something like "prtdiag" in Solaris but like I said, it has been a while...

Quote:

Will this have any effect if you are wanting to netboot a different Sun box? ( I picked up a couple of sparcstations and will probably install/run them this way).....

No, this will not make a difference in netbooting. This requires the proper netboot-image for the particular architecture. Sparcstations will use a 32-bit image while the Ultras use a 64-bit one (actually, only the kernel and perhaps some core utils will differ since most of Sparc/Linux is 32-bit). Of course, once you start the actual install, you would use a different "-mcpu" setting for the sparcstations...