Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio and SPARC specifics)

[Peter Gulutzan]

Hi Vladislav,

This is no longer about gethrtime, it is about SPARC v8.

Vladislav Vaintroub wrote:
> Hello,
>  
> A question regarding  relevancy of v8 and gcc3 on Sparc. By default gcc3.4
> does think the architecture is v8 and compiling my_rdtsc without -mcpu=v9
> would fail. Do you think always adding -mcpu=v9 on solaris/gcc(<4)/sparc
> would be a correct solution for the problem. Or should be declarer gcc(<4)
> also irrelevant. Or is there a way to fix the problem without requiring
> support of the build system (that would of course be preferred solution)?
> 
> I've seen that problem  couple of days ago on Sun machines and Olav have
> seen it too while trying out the -cmake branch. 
<cut>

I first saw the problem in 2008, and Olav probably saw it long before me,
he says he tried to bring it up in discussions of Falcon.

Don't get too encouraged by knowledge that I requested we make it official
that we don't support SPARC v8. I requested in June, and am still waiting.
But, since Olav says the last SPARC v8 was made around 1994 and 5.1 as built
won't run on SPARC v8 anyway, I'm hopeful we'll eventually be able to change.

I don't know why you mention "gcc3" specifically. If gcc4 works differently,
then this problem solves itself if we just wait a few more years.
Sun Studio compiles with the same sort of defaulting; we have to solve for it too.

I don't know why you say "compiling my_rdtsc without -mcpu=v9 would fail".
The compiling shouldn't fail, we have loads of lovely #ifdefs to handle that.
You only mean that the resulting code is sub-optimal, eh?

You ask "is there a way to fix the problem without requiring support of the
build system". I think not.
  Olav suggested that in my_rdtsc.c one could replace
  "&& defined(__sparcv8plus)" with "&& defined(__sparcv8)",
  for details see the collection of excerpts at the end of this email.
  He said he hasn't had time to test that. I expect the test will fail.

I believe that the change would consist of ...
1. A check to make sure the target is SPARC.
2. An assumption that any SPARC target is sparcv8plus at least.
   For my_rdtsc.c I'm happy with sparcv8plus because we'd still get '%tick'
   with either 32-bit or 64-bit. Perhaps others have a sparcv9 requirement.
3. A dismissal of Sun's advice about how to do this
   http://developers.sun.com/sunstudio/downloads/ssx/compilers/readme.html
4. An analysis of the significance of comments like this in our BUILD/build_mccge.sh:
   "
   Solaris/Sparc/Forte
   -------------------
     Uses cc-5.0 as CC
     Sets ASFLAGS=LDFLAGS=xarch=v9, so that we compile Sparc v9 binaries
     C flags   = -Xa -strconst -xc99=none
     C++ flags = -noex
     C/C++ flags = -mt -D_FORTEC -xarch=v9

     For non-debug builds, the following flags are also used:

     C/C++ flags = -xO3
    "
5. An addition of -mcpu (or -march? or -m64?) for gcc, or -xarch for Sun Studio.
   I expect some trouble with the exact wording.
   I have a vague memory that CC -xarch fails on some of our development machines.
   This affects compilation of all .c or .cc files for MySQL Server.
   I don't think we should try to affect assembly of .s files.
   Some fun reading:
   http://blogs.sun.com/quenelle/entry/instruction_set_selection_in_sun
6. I suppose there will be a temptation to say:
   As long as we're changing this, let's look at other compile flags, e.g. optimizer.
   Let us resist such temptation.

I will of course listen obsequiously to whatever opinion Olav delivers,
since my hope is that he will volunteer to fix all our problems as soon
as we get that official stamp.

The rest of this email is a collection of excerpts
from the emails that Olav and I exchanged which mention this,
starting June 2009. Usually you and others were CCed.
Subject lines were
Review of WL#2373 "Use cycle counter for timing" (Sun Studio and SPARC specifics)
Decide to not support SPARC v8

OLAV> "* (Minor issue) On SPARC 32 bit the compiler did not use the inline assembly
> code but used
gethrtime() instead. The reason for this is that __sparcv8plus was not defined. I normally
 run
configure with -m32 to get 32 bits code on SPARC - I could have included __sparcv8plus
when running
configure (I guess). Would an alternative to explicitly check  for __sparcv8plus and
__sparcv9 be to
check the size of a void*? If sizeof(void*) is 4 then it use the 32 bit code, otherwise
use the 64
bit code?"

PETER> I don't think so. It's more than a 32-bit / 64-bit distinction.
As I understand things: with SPARC v8 or earlier, these inline
assembly instructions just won't work. You need SPARC v8+ or later.
Now, should the output of a BUILD (e.g. the binary distributed to
customers) work with SPARC v8, as well as SPARC v8+? I fear so.

OLAV> Does our binaries actually work on a SPARV v8? Do we test it? (another related
> questions: does
any of the Solaris version we are supposed to support run on SPARC v8? I do not know).

OLAV> Unless told otherwise (and I do not know what our official build script does) the
> Sun Studio
compiler will produce code for SPARC V9.

PETER> Our page is vague, it just says "SPARC".
http://dev.mysql.com/doc/refman/5.1/en/connector-mxj-install-platforms.html
Therefore you cannot define __sparcv8plus on the command line
unless you're doing a custom build, and without __sparcv8plus
it's not safe to use the instructions, so you end up with gethrtime.

OLAV> I tried to raise the same question when I did some SPARC assembly for Falcon. I
> probably asked
the wrong people since the answer was relatively vague but I concluded that for Falcon
(and thus
mysql-6.0) it was sufficient to support sparc v8 plus/v9.

PETER> However, when we finally decide we don't need to support SPARC v8,
or when somebody decides to do a custom build and knowingly adds
__sparcv9 or __sparcv8plus, my_rdtsc.c will smoothly switch to
"rd %tick". At least, that's my hopeful logic and intent.

OLAV> I think your logic is fine and should work.

OLAV> About decide to not needing to support SPARC v8: I think that decision should be
> taken now. As
the code is now a default build on SPARC using Sun Studio will likely not have any benefit
from you
excellent work on providing ultra fast assembly implementation of the cycle timer code
(the default
is to build for 32 bit memory model on SPARC).

OLAV> A small fact about SPARC v8: The last processor Sun produced with the SPARC V8
> instruction set
was the super fast SuperSPARC II running at the blazing speed of 90 MHz (in 1994).
(my last SPARC V8 machine run even faster: it had a 125 MHz hyperSPARC....)

PETER> You're saying
* SPARC v8 reached end-of-life long ago.
  (But you're probably not sure where the official statement is.)

OLAV> Correct (and Solaris 10 does not even run on it, while Solaris 8 and 9 support
> it).

PETER> * Default is to produce for SPARC v9.
       (But you're not sure that's true for our builds.)

OLAV> Correct. For 6.0 we used to produce official build as follows: 64 bit code for
> SPARC V9 and
the 32 bit builds for V8 plus. Thus the 6.0.X builds did not support V8.
I have also downloaded the latest official version of 5.1 for SPARC 32 bit for Solaris 9
and this
will not run on a V8 processor either:
os136802@khepri11:~/<2>mysql-5.1.35-solaris9-sparc/bin> file mysqld
mysqld:         ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required,

PETER> * Falcon needs SPARC v9 anyway.

OLAV> Correct, either v8plus or v9. It will not compile if sparc V8 is specified.

PETER> * Even v8plus is totally obsolete.
       (Actually you didn't say that, I'm guessing you believe it.)

OLAV> This one I am unsure of. I do not think it is any harm supporting this for our 32
> bit builds
on SPARC. v8plus should have all the registers (e.g. TICK) and instructions that are
available for
V9 (if I have understood it correctly).

PETER> We need an official statement, something similar to the
one about AIX 5.2 on this page:
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-34.html
The problem is, that's about operating system.
We need to say about hardware. And currently we
only have a vague statement that we still support SPARC.
http://www.mysql.com/support/supportedplatforms/enterprise.html
Trudy tells me that the person who can help
with such "end of life" policy statements is
[ name redacted, see original email ].
So, I guess that one of us (you or me or Staale) should
contact [ name redacted ] and ensure it's okay to announce stopping
support of SPARC v8 (including v8plus?) starting with version x.
I hope version x is 5.4.4.
But if it isn't, as I've understood matters,
that won't affect your approval of the timer code. It will just start to work better when
we can say
'gcc -mcpu=v9 -m32' or '/cc/ -/xarch/=/v8plus'/ which requires configure.in changes. You
volunteer?

OLAV> Correct. I have no problem approving the code as it is - just feels a bit wrong
> that we have
good optimal code for SPARC 32 that we do not use due to we still try to support SPARC V8.

I think this also can be solved by adding a special check in the code to check for SPARC
V8
explicitely, eg. replace the check for __sparcv8plus with ! __sparcv8 in the following
code:

#elif (defined(__SUNPRO_CC) || defined(__SUNPRO_C)) && defined(__sparcv8plus)
&& defined(_ILP32) &&
!defined(__SunOS_5_7)

to

#elif (defined(__SUNPRO_CC) || defined(__SUNPRO_C)) && !defined(__sparcv8)
&& defined(_ILP32) &&
!defined(__SunOS_5_7)

(note: I have not had the time to test this today but an happy to volunteer to test it).

Back to the original topic of your email: I agree that we officially should make a
statement that we
no longer support SPARC V8 for the 5.4.X release. I think it is the owner of the release
who should
have the responsibility for determining what OSes and hardware a release should support

PETER> 5. Declare SPARC v8 end-of-support and add what we
   need so that __sparcv8plus or __sparcv9 are defined
   when compiling my_rdtsc.c. We're discussing this in
   separate emails. Regardless whether that discussion
   leads to success, I think we can't get approval
   quickly enough (confirm this with Staale Deraas if
   you see him), we'll have to get by with gethrtime


-- 

Peter Gulutzan
Database Group / MySQL www.mysql.com
Sun Microsystems of Canada Inc.
Edmonton, AB, Canada