sparc64 support for Solaris

sparc64 support for Solaris

[Fred Richardson]

Hi-

I was wondering how I can enable 64 bit support and v9 instruction
scheduling for an Ultra 1 Model 170 running Solaris2.5.  This is
apparently not possible when the target is "sparc-sun-solaris2.5.1".

I thought I'd try specifying "sparc64-sun-elf".  But I don't know if
this makes any sense.  Does anyone have any suggestions?

                    -Fred

Re: sparc64 support for Solaris

[David S. Miller]

   Date: Fri, 17 Oct 1997 19:51:35 -0400
   From: Fred Richardson <frichard@bbn.com>

   I was wondering how I can enable 64 bit support and v9 instruction
   scheduling for an Ultra 1 Model 170 running Solaris2.5.  This is
   apparently not possible when the target is
   "sparc-sun-solaris2.5.1".

   I thought I'd try specifying "sparc64-sun-elf".  But I don't know
   if this makes any sense.  Does anyone have any suggestions?

Solaris still lacks any 64-bit userland support on UltraSparc systems.

However you can get Ultra optimized instruction scheduling by passing
"-mcpu=ultrasparc" to egcs.

Later,
David "Sparc" Miller
davem@caip.rutgers.edu

Re: sparc64 support for Solaris

[Joe Buck]

> I was wondering how I can enable 64 bit support and v9 instruction
> scheduling for an Ultra 1 Model 170 running Solaris2.5.  This is
> apparently not possible when the target is "sparc-sun-solaris2.5.1".

If you turned it on, your process would bomb at the first context switch.
Solaris 2.5.x does not save the 64-bit register state, so basically some
registers will come back randomized (from other processes?).

Solaris 2.6 is supposed to fix this.  Also, HAL/OS, HAL's patched
version of Solaris 2.4, fixes it.  So please don't turn it on on 2.5.1
(unless you are cross-compiling).  Very bad things will happen.

Re: sparc64 support for Solaris

[John Carr]

> > I was wondering how I can enable 64 bit support and v9 instruction
> > scheduling for an Ultra 1 Model 170 running Solaris2.5.
> 
> If you turned it on, your process would bomb at the first context switch.
> Solaris 2.5.x does not save the 64-bit register state, so basically some
> registers will come back randomized (from other processes?).

Not randomized, zero extended.

All 64 bits of the global and out registers are preserved over a
context switch.  I've made some changes to take advantage of this for
certain 64 bit operations in 32 bit mode (e.g. cmpdi is inline).  This
is effectively a peephole optimization -- I don't keep 64 bit registers
live across gcc instruction boundaries because that would be too hard.

> Solaris 2.6 is supposed to fix this.

2.6 is the same as 2.5, I'm told.  2.7 (next summer?) will support 64
bit processes.

Re: sparc64 support for Solaris

[Oleg Krivosheev]

On Fri, 17 Oct 1997, Joe Buck wrote:

> > I was wondering how I can enable 64 bit support and v9 instruction
> > scheduling for an Ultra 1 Model 170 running Solaris2.5.  This is
> > apparently not possible when the target is "sparc-sun-solaris2.5.1".
> 
> If you turned it on, your process would bomb at the first context switch.
> Solaris 2.5.x does not save the 64-bit register state, so basically some
> registers will come back randomized (from other processes?).

hmm...
are you sure ?
Solaris2.5.1 ultra != solaris 2.5.1 32bit sparc.

> Solaris 2.6 is supposed to fix this.  

no

64bit interface will be in Solaris 2.7, Q1 next year i've heard

OK

Re: sparc64 support for Solaris

[Joe Buck]

> > Solaris 2.5.x does not save the 64-bit register state, so basically some
> > registers will come back randomized (from other processes?).
> 
> hmm...
> are you sure ?
> Solaris2.5.1 ultra != solaris 2.5.1 32bit sparc.

I am quite certain.

> > Solaris 2.6 is supposed to fix this.  
> 
> no
> 64bit interface will be in Solaris 2.7, Q1 next year i've heard

I was told "fixed in 2.6" by Sun people over a year ago.  Possibly
it slipped.

Re: sparc64 support for Solaris

[Joe Buck]

> > > Solaris 2.5.x does not save the 64-bit register state, so basically some
> > > registers will come back randomized (from other processes?).
> > 
> > hmm...
> > are you sure ?
> > Solaris2.5.1 ultra != solaris 2.5.1 32bit sparc.

I said:
> I am quite certain.

That is, I am quite certain that there is a problem.  I was not
certain (or correct) about the details.

Well, as has been pointed out, they are zero-extended, not random,
but the essense is that user-mode 64-bit code is unsafe.

Re: sparc64 support for Solaris

[Mike Stump]

> Date: Fri, 17 Oct 1997 19:51:35 -0400
> From: Fred Richardson <frichard@bbn.com>

> I was wondering how I can enable 64 bit support and v9 instruction
> scheduling for an Ultra 1 Model 170 running Solaris2.5.  This is
> apparently not possible when the target is "sparc-sun-solaris2.5.1".

> I thought I'd try specifying "sparc64-sun-elf".  But I don't know if
> this makes any sense.  Does anyone have any suggestions?

from sparc.c:

    /* "v9" is used to specify a true 64 bit architecture.
       "v8plus" is what Sun calls Solaris2 running on UltraSPARC's.  */
    { "v8plus",     PROCESSOR_V8PLUS, MASK_ISA, MASK_V9 },

Now, do you want to help us, and submit changes to the doc that
document this better so that next time we can say RTFM?  ;-)

-mcpu=v8plus should work.

Re: sparc64 support for Solaris

[Fred Richardson]

>> Now, do you want to help us, and submit changes to the doc that
>> document this better so that next time we can say RTFM?  ;-)

I would like to, but I'm still confused...

    Sun describes my machine (Ultra 1 Model 170) as having a 64 bit,
    v9 instruction set CPU.  It sounds like (based on the last few
    mailings on this topic) Sol2.5.x doesn't support 64 bit context
    switches.  Now, I noticed that "v9" and "sparc64" must both be
    true (you can't have one without the other).  Is this an inherent
    limitation for sparc-sol2.5, or is this a yet to be resolved
    issue for GCC's sparc support?

    Given all that, are these statements accurate?

    >> "v9" is used to specify a true 64 bit architecture.

    So an Ultra 1 Model 170 is not "true 64 bit" if it's running
    Sol2.5.x  Could it be 64 bit if it's running some other
    (newer) version of Solaris.

    >> "v8plus" is what Sun calls Solaris2 running on UltraSPARC's.

    But then what does -mcpu=ultrasparc mean?   Is there a difference
    between this and -mcpu=v8plus?

    Also, this sounds discouraging:
        sparc.h:123    /* ??? v8plus/v9/ultrasparc handling is tentative */
    I wonder if this implies that the support isn't really there yet.

I don't know the answers to these.  I also read in the Sun CC man page
that specifying "-fast" causes a set of inline math functions to be
used.  I wonder if I can use these with GCC...

            -Fred

    

Re: sparc64 support for Solaris

[John Carr]

>     Sun describes my machine (Ultra 1 Model 170) as having a 64 bit,
>     v9 instruction set CPU. 

True.

> It sounds like (based on the last few mailings on this topic) Sol2.5.x
> doesn't support 64 bit context switches.

Basically true, but you can lose the high bits of inactive register
windows and the "in" registers without a context switch.  A register
window overflow is enough because the stack frame only reserves 32
bits per register to save them.

> Now, I noticed that "v9" and "sparc64" must both be true (you can't
> have one without the other).

v9 = the extra instructions added in V9.

sparc64 = use 64 bit registers instead of 32; since SPARC V8 doesn't
define 64 bit registers this implies V9.

The latter is not supported on Solaris 2.5 or 2.6.  Even if you wrote
all new 64 bit libraries the kernel register window save code doesn't
support 64 bit user mode stacks.  (The support is actually there in
the kernel for use in kernel mode but there is no way for a user mode
process to set the bits which mean "I might use 64 bit mode".)

>     >> "v9" is used to specify a true 64 bit architecture.

No.  It selects the V9 instruction set but does not enable use of 64
bit registers.  There are many minor ways in which 32-bit V9 is
different from V8.  For example, the effects of a "wr" instruction may
not be visible for 3 instructions in SPARC V8 but are visibile
immediately in SPARC V9.

>     >> "v8plus" is what Sun calls Solaris2 running on UltraSPARC's.
> 
>     But then what does -mcpu=ultrasparc mean?   Is there a difference
>     between this and -mcpu=v8plus?

I don't think v8plus is a useful option in egcs yet, but I have
changes which make v8plus mode take advantage of some 64 bit
instructions operating on global and out registers (which are not
randomly clobbered).

Re: sparc64 support for Solaris

[Doug Evans]

   Date: Sun, 19 Oct 1997 16:05:50 -0400
   From: Fred Richardson <frichard@bbn.com>

   >> Now, do you want to help us, and submit changes to the doc that
   >> document this better so that next time we can say RTFM?  ;-)

   I would like to, but I'm still confused...

       Sun describes my machine (Ultra 1 Model 170) as having a 64 bit,
       v9 instruction set CPU.  It sounds like (based on the last few
       mailings on this topic) Sol2.5.x doesn't support 64 bit context
       switches.

As has been noted elsewhere, the full 64 bits of %g and %o
are saved, but that's it.  I haven't seen jfc's patch for cmpdi/etc.
but in general getting GCC to efficiently support this isn't something
I've wanted to spend time on [though others might].

       Now, I noticed that "v9" and "sparc64" must both be
       true (you can't have one without the other).  Is this an inherent
       limitation for sparc-sol2.5, or is this a yet to be resolved
       issue for GCC's sparc support?

Inherent limitation.  You have to distinguish between what the cpu
provides and what the o/s provides.

       Given all that, are these statements accurate?

       >> "v9" is used to specify a true 64 bit architecture.

       So an Ultra 1 Model 170 is not "true 64 bit" if it's running
       Sol2.5.x  Could it be 64 bit if it's running some other
       (newer) version of Solaris.

Yes.

       >> "v8plus" is what Sun calls Solaris2 running on UltraSPARC's.

       But then what does -mcpu=ultrasparc mean?   Is there a difference
       between this and -mcpu=v8plus?

The difference is that specifying -mcpu=ultrasparc tells gcc to schedule
code for the ultrasparc,  -mcpu=v8plus doesn't specify a particular
pipeline to schedule for.

Also note that no one has spent time tuning the sparc port for the
haifa scheduler [at least I haven't seen any patches], so enabling
the haifa scheduler for the sparc port won't buy as much as it technically
can.

       Also, this sounds discouraging:
	   sparc.h:123    /* ??? v8plus/v9/ultrasparc handling is tentative */
       I wonder if this implies that the support isn't really there yet.

Depends upon how you define "support".  The point about being "tentative"
is that when that was written, there was no 64 bit o/s [ok, there is HAL's
port of Solaris, but egcs/gcc2 doesn't support that]. [I realize linux64
may have existed at that time, but the gcc work to finish the port
hadn't been completed yet, hence the word "tentative"].

   I don't know the answers to these.  I also read in the Sun CC man page
   that specifying "-fast" causes a set of inline math functions to be
   used.  I wonder if I can use these with GCC...

Nope.  But then what are these inline functions?  If they're just
cover functions to hardware instructions, one could write ones own
[e.g. see math-68881.h in the gcc sources].