Indy 64 or 32 bit?

Indy 64 or 32 bit?

[Brandon Barker]

I will be purchasing 2 SGI Indy R5000 models from reputable.com, and was 
curious if these are 64 bit systems or 32 bit systems (for that matter, are 
all/any Indys 32 or 64 bit systems).  My guess is 64 because I wiould think 
IRIX has been 64 for quite some time, but was curious.  I use Linux on x86 
but will probably use IRIX for a few weeks on the Indy's until I become 
familiar enough with the machines to try installing Linux.  BTW, does gcc 
work on IRIX?

Thanks for the info,
Brandon Barker

Re: Indy 64 or 32 bit?

[George Gensure]

The R5000 Indies are, in my experience 32 bit systems.  Feel free to smack me
down if anyone has contrary information, however.

George Gensure

On Mon, 6 Aug 2001, Brandon Barker wrote:

> I will be purchasing 2 SGI Indy R5000 models from reputable.com, and was
> curious if these are 64 bit systems or 32 bit systems (for that matter, are
> all/any Indys 32 or 64 bit systems).  My guess is 64 because I wiould think
> IRIX has been 64 for quite some time, but was curious.  I use Linux on x86
> but will probably use IRIX for a few weeks on the Indy's until I become
> familiar enough with the machines to try installing Linux.  BTW, does gcc
> work on IRIX?
>
> Thanks for the info,
> Brandon Barker
>

Re: Indy 64 or 32 bit?

[nick]

IRIX runs indys 32bit.  I would assume it runs the challange s 32bit as
well, though I'm not sure.  All SGIs newer than the indigo (so the indy,
i2, etc) support 64bit mode, though some early indy/i2 proms may not be
able to deal with 64bit code.
	Nick

On Mon, 6 Aug 2001, George Gensure wrote:

> The R5000 Indies are, in my experience 32 bit systems.  Feel free to smack me
> down if anyone has contrary information, however.
> 
> George Gensure
> 
> On Mon, 6 Aug 2001, Brandon Barker wrote:
> 
> > I will be purchasing 2 SGI Indy R5000 models from reputable.com, and was
> > curious if these are 64 bit systems or 32 bit systems (for that matter, are
> > all/any Indys 32 or 64 bit systems).  My guess is 64 because I wiould think
> > IRIX has been 64 for quite some time, but was curious.  I use Linux on x86
> > but will probably use IRIX for a few weeks on the Indy's until I become
> > familiar enough with the machines to try installing Linux.  BTW, does gcc
> > work on IRIX?
> >
> > Thanks for the info,
> > Brandon Barker
> >
> 

Re: Indy 64 or 32 bit?

[Nils C. Anderson]

    Indy and Challenge S under Irix are 32 bits.

to verify just run `uname`

if it returns "IRIX" == 32 bit
if "IRIX64" == 64 bit.

Andy


----- Original Message -----
From: <nick@snowman.net>
To: "George Gensure" <werkt@csh.rit.edu>
Cc: "Brandon Barker" <bebarker@meginc.com>; <linux-mips@oss.sgi.com>
Sent: Tuesday, August 07, 2001 12:03 AM
Subject: Re: Indy 64 or 32 bit?


> IRIX runs indys 32bit.  I would assume it runs the challange s 32bit as
> well, though I'm not sure.  All SGIs newer than the indigo (so the indy,
> i2, etc) support 64bit mode, though some early indy/i2 proms may not be
> able to deal with 64bit code.
> Nick
>
> On Mon, 6 Aug 2001, George Gensure wrote:
>
> > The R5000 Indies are, in my experience 32 bit systems.  Feel free to
smack me
> > down if anyone has contrary information, however.
> >
> > George Gensure
> >
> > On Mon, 6 Aug 2001, Brandon Barker wrote:
> >
> > > I will be purchasing 2 SGI Indy R5000 models from reputable.com, and
was
> > > curious if these are 64 bit systems or 32 bit systems (for that
matter, are
> > > all/any Indys 32 or 64 bit systems).  My guess is 64 because I wiould
think
> > > IRIX has been 64 for quite some time, but was curious.  I use Linux on
x86
> > > but will probably use IRIX for a few weeks on the Indy's until I
become
> > > familiar enough with the machines to try installing Linux.  BTW, does
gcc
> > > work on IRIX?
> > >
> > > Thanks for the info,
> > > Brandon Barker
> > >
> >
>
>

Re: Indy 64 or 32 bit?

[Nils C. Anderson]

    Indy and Challenge S under Irix are 32 bits.

to verify just run `uname`

if it returns "IRIX" == 32 bit
if "IRIX64" == 64 bit.

Andy


----- Original Message -----
From: <nick@snowman.net>
To: "George Gensure" <werkt@csh.rit.edu>
Cc: "Brandon Barker" <bebarker@meginc.com>; <linux-mips@oss.sgi.com>
Sent: Tuesday, August 07, 2001 12:03 AM
Subject: Re: Indy 64 or 32 bit?


> IRIX runs indys 32bit.  I would assume it runs the challange s 32bit as
> well, though I'm not sure.  All SGIs newer than the indigo (so the indy,
> i2, etc) support 64bit mode, though some early indy/i2 proms may not be
> able to deal with 64bit code.
> Nick
>
> On Mon, 6 Aug 2001, George Gensure wrote:
>
> > The R5000 Indies are, in my experience 32 bit systems.  Feel free to
smack me
> > down if anyone has contrary information, however.
> >
> > George Gensure
> >
> > On Mon, 6 Aug 2001, Brandon Barker wrote:
> >
> > > I will be purchasing 2 SGI Indy R5000 models from reputable.com, and
was
> > > curious if these are 64 bit systems or 32 bit systems (for that
matter, are
> > > all/any Indys 32 or 64 bit systems).  My guess is 64 because I wiould
think
> > > IRIX has been 64 for quite some time, but was curious.  I use Linux on
x86
> > > but will probably use IRIX for a few weeks on the Indy's until I
become
> > > familiar enough with the machines to try installing Linux.  BTW, does
gcc
> > > work on IRIX?
> > >
> > > Thanks for the info,
> > > Brandon Barker
> > >
> >
>
>

Re: Indy 64 or 32 bit?

[Ralf Baechle]

On Mon, Aug 06, 2001 at 11:47:36PM -0400, Brandon Barker wrote:

> I will be purchasing 2 SGI Indy R5000 models from reputable.com, and was 
> curious if these are 64 bit systems or 32 bit systems (for that matter, are 
> all/any Indys 32 or 64 bit systems).  My guess is 64 because I wiould think 
> IRIX has been 64 for quite some time, but was curious.  I use Linux on x86 
> but will probably use IRIX for a few weeks on the Indy's until I become 
> familiar enough with the machines to try installing Linux.  BTW, does gcc 
> work on IRIX?

By hardwareware it's a 64-bit system - like all SGI systems we support.
The kernel is just a 32-bit one though which is a reasonable compromise
for these systems.

  Ralf

Re: Indy 64 or 32 bit?

[J. Scott Kasten]

Well, it's kind of both.  The R4000 and up are 64 bit CPU's capable of
running either 32 or 64 bit code.  The MIPS address space is a little
wierd such that you can kinda munge 32 and 64 bit code togeather under the
right circumstances.

Some of the old hands here could tell you better how Irix behaves on those
boxes.  I know you can compile code with 64 bit int and pointers and it
will run on those boxes under Irix, but there is a little more to it than
that.

Yes, gcc works under Irix.  I think most of Reputable's Indy's have Irix
6.2 loaded on them, which is probably the minimum you would want to run
gcc under.  You will have to download the IDF and IDL from SGI (about
500MB worth of stuff) to make gcc work.  It relies on having the official
Irix /usr/include, compiler libraries, and the navtive Irix
assembler/linker.  I've used the gcc-2.95.2 found on SGI's freeware site.
It seems quite solid.  The only caveat to using gcc with Irix is that gcc
and the native compiler differ in how they pass data structures as
arguments to functions, or as return values.  I'm not talking about
pointers to structs, but actual structs as the targets.  Code that does
that will break.  Thankfully, that's rare, but there are a few stdlib
cases such as semiphore operations.

I've used both linux and Irix on the Indy.  Quite frankly, I would
consider getting a second HD if cheep enough so that you could keep both
around.  (Note: don't put 2 high RPM drives in the Indy, or we are talking
melt down of your pretty blue toy...)

I've found much to like in Irix in addition to the flexibility of Linux.

On Mon, 6 Aug 2001, Brandon Barker wrote:

> I will be purchasing 2 SGI Indy R5000 models from reputable.com, and was
> curious if these are 64 bit systems or 32 bit systems (for that matter, are
> all/any Indys 32 or 64 bit systems).  My guess is 64 because I wiould think
> IRIX has been 64 for quite some time, but was curious.  I use Linux on x86
> but will probably use IRIX for a few weeks on the Indy's until I become
> familiar enough with the machines to try installing Linux.  BTW, does gcc
> work on IRIX?
>
> Thanks for the info,
> Brandon Barker
>

Re: Indy 64 or 32 bit?

[Ralf Baechle]

On Tue, Aug 07, 2001 at 08:45:17PM -0400, J. Scott Kasten wrote:

> Well, it's kind of both.  The R4000 and up are 64 bit CPU's capable of
> running either 32 or 64 bit code.  The MIPS address space is a little
> wierd such that you can kinda munge 32 and 64 bit code togeather under the
> right circumstances.

Right circumstances = almost always.  Actually Linux makes sure that it's
indeed always.

> Some of the old hands here could tell you better how Irix behaves on those
> boxes.  I know you can compile code with 64 bit int and pointers and it
> will run on those boxes under Irix, but there is a little more to it than
> that.

That's not supported on all systems.  An Indy for example is limited to
128mb RAM as shipped by SGI (256 with aftermarket parts).  There is no
point in supporting 64-bit address space on such a system and so SGI doesn't
support only N32.

> I've used both linux and Irix on the Indy.  Quite frankly, I would
> consider getting a second HD if cheep enough so that you could keep both
> around.  (Note: don't put 2 high RPM drives in the Indy, or we are talking
> melt down of your pretty blue toy...)

External drives work just fine and can be hidden where their sound isn't so
annoying.

> I've found much to like in Irix in addition to the flexibility of Linux.

Yep and they co-exist nicely.

  Ralf

Re: Indy 64 or 32 bit?

[J. Scott Kasten]

On Wed, 8 Aug 2001, Ralf Baechle wrote:

> On Tue, Aug 07, 2001 at 08:45:17PM -0400, J. Scott Kasten wrote:

> Right circumstances = almost always.  Actually Linux makes sure that it's
> indeed always.

As long as our data doesn't make sparse use of the VM address space,
yes...  I always have to think of the worst case.  ;-)

> > Some of the old hands here could tell you better how Irix behaves on those
> > boxes.  I know you can compile code with 64 bit int and pointers and it
> > will run on those boxes under Irix, but there is a little more to it than
> > that.
>
> That's not supported on all systems.  An Indy for example is limited to
> 128mb RAM as shipped by SGI (256 with aftermarket parts).  There is no
> point in supporting 64-bit address space on such a system and so SGI doesn't
> support only N32.

Well, that actually brings to mind a nagging question I've had in regards
to just what N32 is.  Here's an example app and creative use of gcc:

/* Note: stdio.h deliberately left out to bypass some syntax issues. */

int main(int argc, char *agv[]) {
        int i, *j;

        printf(
          "sizeof(int) = %1d, sizeof(*) = %1d\n",
          sizeof(i),
          sizeof(j)
        );

        j = &i;
        *j = 10;
        i++;

        printf(
          "Result: %1d\n",
          (int) *j
        );

        return (0);
}

Compile:

   gcc -mips3 -mint64 test.c -o test

The file command says:

  test:           ELF N32 MSB mips-3 dynamic executable (not stripped) MIPS - version 1

Run:

  sizeof(int) = 8, sizeof(*) = 8
  Result: 11

If we look at the assembly, we see a sign extended 64 bit load, and a 64
bit add.  So we are indeed generating 64 bit instructions, at least in
some cases.

        dli $3,0xa # 10
        <snip>
        daddu $3,$2,1

Does N32 legitimately allow 64 bit instructions, or is this an example of
code that I've truely "munged" togeather?  It clearly works, at least in
this trivial case.

I'm just trying to solidify my understanding of what Irix is supposed to
do.

Re: Indy 64 or 32 bit?

[Ralf Baechle]

On Wed, Aug 08, 2001 at 11:02:44AM -0400, J. Scott Kasten wrote:

>    gcc -mips3 -mint64 test.c -o test
> 
> The file command says:
> 
>   test:           ELF N32 MSB mips-3 dynamic executable (not stripped) MIPS - version 1
> 
> Run:
> 
>   sizeof(int) = 8, sizeof(*) = 8
>   Result: 11
> 
> If we look at the assembly, we see a sign extended 64 bit load, and a 64
> bit add.  So we are indeed generating 64 bit instructions, at least in
> some cases.
> 
>         dli $3,0xa # 10
>         <snip>
>         daddu $3,$2,1
> 
> Does N32 legitimately allow 64 bit instructions,

Yes.  Hey, that's the 80% of the purpose of N32!

> or is this an example of code that I've truely "munged" togeather?

Doubleplusyesyesyes :-)  -mint64 is not valid for any MIPS code model.  Gas
is royally b0rken for N32.  If you really want to read about N32 get the
respective docs from techpubs.sgi.com.

  Ralf

Re: Indy 64 or 32 bit?

[Thiemo Seufer]

Ralf Baechle wrote:
> On Wed, Aug 08, 2001 at 11:02:44AM -0400, J. Scott Kasten wrote:
> 
> >    gcc -mips3 -mint64 test.c -o test
> > 
> > The file command says:
> > 
> >   test:           ELF N32 MSB mips-3 dynamic executable (not stripped) MIPS - version 1
                          ^^^
I don't know how file detects this, but at least current CVS gas
does not set the appropriate flag in the object file header.

> > 
> > Run:
> > 
> >   sizeof(int) = 8, sizeof(*) = 8
                    ^              ^
This should be both 4, I assume this happened due to -mint64.

> >   Result: 11
> > 
> > If we look at the assembly, we see a sign extended 64 bit load, and a 64
> > bit add.  So we are indeed generating 64 bit instructions, at least in
> > some cases.
> > 
> >         dli $3,0xa # 10

To what does this dli get expanded? I'm interested in the output of
objdump -d.

[snip]
> > or is this an example of code that I've truely "munged" togeather?
> 
> Doubleplusyesyesyes :-)  -mint64 is not valid for any MIPS code model.  Gas
> is royally b0rken for N32.

WRT what?


Thiemo

Re: Indy 64 or 32 bit?

[J. Scott Kasten]

On Wed, 8 Aug 2001, Thiemo Seufer wrote:

> Ralf Baechle wrote:
> > On Wed, Aug 08, 2001 at 11:02:44AM -0400, J. Scott Kasten wrote:
> >
> > >    gcc -mips3 -mint64 test.c -o test
> > >
> > > The file command says:
> > >
> > >   test:           ELF N32 MSB mips-3 dynamic executable (not stripped) MIPS - version 1
>                           ^^^
> I don't know how file detects this, but at least current CVS gas
> does not set the appropriate flag in the object file header.

Gas does not apply here.  We're talking about gcc running under Irix with
the native as and ld tools.  I'm using gcc-2.91.66 (egcs-1.1.2),
gcc-2.95.2, MipsPro 7.30 as and ld.

> > >
> > > Run:
> > >
> > >   sizeof(int) = 8, sizeof(*) = 8
>                     ^              ^
> This should be both 4, I assume this happened due to -mint64.

Not totally.  -mips3 generates values of 4 and 8.  The -mint64 takes it to
8 and 8.  If I just invoke gcc with no -m flags, it does produce 4 and 4.

> > > If we look at the assembly, we see a sign extended 64 bit load, and a 64
> > > bit add.  So we are indeed generating 64 bit instructions, at least in
> > > some cases.
> > >
> > >         dli $3,0xa # 10
>
> To what does this dli get expanded? I'm interested in the output of
> objdump -d.


test.S

        sd      $2,40($fp)
        ld      $2,40($fp)
        dli     $3,0xa          # 10
        sd      $3,0($2)
        ld      $2,32($fp)
        daddu   $3,$2,1
        sd      $3,32($fp)
        ld      $2,40($fp)

objdump -d

    100012b0:   ffc20028        sd      $v0,40($s8)
    100012b4:   dfc20028        ld      $v0,40($s8)
    100012b8:   2403000a        li      $v1,10
    100012bc:   fc430000        sd      $v1,0($v0)
    100012c0:   dfc20020        ld      $v0,32($s8)
    100012c4:   64430001        daddiu  $v1,$v0,1
    100012c8:   ffc30020        sd      $v1,32($s8)
    100012cc:   dfc20028        ld      $v0,40($s8)


Just for kicks, instead of *j = 10, which is trivial, I picked a true 64
bit constant:

        sd      $2,40($fp)
        ld      $2,40($fp)
        dli     $3,0x807060504030201
        sd      $3,0($2)
        ld      $2,32($fp)
        daddu   $3,$2,1
        sd      $3,32($fp)
        ld      $2,40($fp)


    100012b0:   ffc20028        sd      $v0,40($s8)
    100012b4:   dfc20028        ld      $v0,40($s8)
    100012b8:   3c030807        lui     $v1,0x807
    100012bc:   34630605        ori     $v1,$v1,0x605
    100012c0:   00031c38        dsll    $v1,$v1,0x10
    100012c4:   34630403        ori     $v1,$v1,0x403
    100012c8:   00031c38        dsll    $v1,$v1,0x10
    100012cc:   34630201        ori     $v1,$v1,0x201
    100012d0:   fc430000        sd      $v1,0($v0)
    100012d4:   dfc20020        ld      $v0,32($s8)
    100012d8:   64430001        daddiu  $v1,$v0,1
    100012dc:   ffc30020        sd      $v1,32($s8)
    100012e0:   dfc20028        ld      $v0,40($s8)

Ouch that's a painfull load.  It's interesting that in both cases, it
effectively makes the constant load a 16 bit operation, does the math 64
bit, and stores 64 bit.

Re: Indy 64 or 32 bit?

[Thiemo Seufer]

J. Scott Kasten wrote:
[snip]
> > I don't know how file detects this, but at least current CVS gas
> > does not set the appropriate flag in the object file header.
> 
> Gas does not apply here.  We're talking about gcc running under Irix with
> the native as and ld tools.  I'm using gcc-2.91.66 (egcs-1.1.2),
> gcc-2.95.2, MipsPro 7.30 as and ld.

Sorry, I have missed this.

> > > >
> > > > Run:
> > > >
> > > >   sizeof(int) = 8, sizeof(*) = 8
> >                     ^              ^
> > This should be both 4, I assume this happened due to -mint64.
> 
> Not totally.  -mips3 generates values of 4 and 8.  The -mint64 takes it to
> 8 and 8.  If I just invoke gcc with no -m flags, it does produce 4 and 4.

n32 ABI uses sizeof(void *) == 4, so something went wrong here.

[snip]
> Just for kicks, instead of *j = 10, which is trivial, I picked a true 64
> bit constant:

Are you a telepathic? :-)

>         sd      $2,40($fp)
>         ld      $2,40($fp)
>         dli     $3,0x807060504030201
>         sd      $3,0($2)
>         ld      $2,32($fp)
>         daddu   $3,$2,1
>         sd      $3,32($fp)
>         ld      $2,40($fp)
> 
> 
>     100012b0:   ffc20028        sd      $v0,40($s8)
>     100012b4:   dfc20028        ld      $v0,40($s8)
>     100012b8:   3c030807        lui     $v1,0x807
>     100012bc:   34630605        ori     $v1,$v1,0x605
>     100012c0:   00031c38        dsll    $v1,$v1,0x10
>     100012c4:   34630403        ori     $v1,$v1,0x403
>     100012c8:   00031c38        dsll    $v1,$v1,0x10
>     100012cc:   34630201        ori     $v1,$v1,0x201
>     100012d0:   fc430000        sd      $v1,0($v0)
>     100012d4:   dfc20020        ld      $v0,32($s8)
>     100012d8:   64430001        daddiu  $v1,$v0,1
>     100012dc:   ffc30020        sd      $v1,32($s8)
>     100012e0:   dfc20028        ld      $v0,40($s8)
> 
> Ouch that's a painfull load.  It's interesting that in both cases, it
> effectively makes the constant load a 16 bit operation, does the math 64
> bit, and stores 64 bit.

Loading constants via 16bit immediates is normal and the fastest
way on MIPS. The really interesting part is that the load avoids
clobbering $at. For superscalar processors it's faster to do e.g.

        lui     $v1,0x807
        lui     $at,$at,0x403
        ori     $v1,$v1,0x605
        ori     $at,$at,0x201
        dsll32  $v1,$v1,0x0
        or      $v1,$v1,$at

with a critical path length of 4 instead of 6.


Thiemo

Re: Indy 64 or 32 bit?

[Ralf Baechle]

On Wed, Aug 08, 2001 at 04:12:39PM -0400, J. Scott Kasten wrote:

>     100012b0:   ffc20028        sd      $v0,40($s8)
>     100012b4:   dfc20028        ld      $v0,40($s8)
>     100012b8:   3c030807        lui     $v1,0x807
>     100012bc:   34630605        ori     $v1,$v1,0x605
>     100012c0:   00031c38        dsll    $v1,$v1,0x10
>     100012c4:   34630403        ori     $v1,$v1,0x403
>     100012c8:   00031c38        dsll    $v1,$v1,0x10
>     100012cc:   34630201        ori     $v1,$v1,0x201
>     100012d0:   fc430000        sd      $v1,0($v0)
>     100012d4:   dfc20020        ld      $v0,32($s8)
>     100012d8:   64430001        daddiu  $v1,$v0,1
>     100012dc:   ffc30020        sd      $v1,32($s8)
>     100012e0:   dfc20028        ld      $v0,40($s8)
> 
> Ouch that's a painfull load.  It's interesting that in both cases, it
> effectively makes the constant load a 16 bit operation, does the math 64
> bit, and stores 64 bit.

With GP optimization something like the following would have been created:

	dla	$gp, _gp + $8000

	ld	$reg1, %gprel(var)($gp)
	daddiu	$reg1, $reg1, 1
	sd	$reg1, %gprel(var)($gp)

_gp:
var:	.word	0

Gas is lame.  MIPS/ELF gas is more.

  Ralf