Skip to contentSkip to conversation

Indy 64 or 32 bit?

DISCUSSION Brandon Barker 7 participants 13 messages Aug 7, 2001 – Aug 9, 2001 MIPS

lore
Share & tools
lore

Brandon Barker

author
#0 lore raw

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

#1 lore raw

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

George Gensure

Quoted 11 lines · 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

#2 lore raw

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

Quoted 19 lines · 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

Quoted 11 lines · 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

#3 lore raw

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: <[email protected]>
To: "George Gensure" <[email protected]>
Cc: "Brandon Barker" <[email protected]>; <[email protected]>
Sent: Tuesday, August 07, 2001 12:03 AM
Subject: Re: Indy 64 or 32 bit?

Quoted 9 lines

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

Quoted 1 line · George Gensure

The R5000 Indies are, in my experience 32 bit systems. Feel free to

smack me

Quoted 7 lines
Quoted 7 lines

down if anyone has contrary information, however.

George Gensure

Quoted 1 line · Brandon Barker

I will be purchasing 2 SGI Indy R5000 models from reputable.com, and

was

Quoted 1 line
Quoted 1 line
Quoted 1 line

curious if these are 64 bit systems or 32 bit systems (for that

matter, are

Quoted 1 line
Quoted 1 line
Quoted 1 line

all/any Indys 32 or 64 bit systems). My guess is 64 because I wiould

think

Quoted 1 line
Quoted 1 line
Quoted 1 line

IRIX has been 64 for quite some time, but was curious. I use Linux on

x86

Quoted 1 line
Quoted 1 line
Quoted 1 line

but will probably use IRIX for a few weeks on the Indy's until I

become

Quoted 1 line
Quoted 1 line
Quoted 1 line

familiar enough with the machines to try installing Linux. BTW, does

gcc

Quoted 8 lines
Quoted 6 lines
Quoted 5 lines

work on IRIX?

Thanks for the info,
Brandon Barker

#4 lore raw
In reply to Brandon Barker
Quoted 7 lines · 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?

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

#5 lore raw
In reply to Brandon Barker

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.

Quoted 11 lines · 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

#6 lore raw
Quoted 4 lines · 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.

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

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 1 line

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

Yep and they co-exist nicely.

Ralf

#7 lore raw
Quoted 4 lines · Ralf Baechle

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. ;-)

Quoted 9 lines
Quoted 4 lines

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.

#8 lore raw
Quoted 15 lines · J. Scott Kasten

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.

Quoted 5 lines
        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!

Quoted 1 line

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

#9 lore raw
Quoted 7 lines · Ralf Baechle
Quoted 5 lines · J. Scott Kasten

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.

Quoted 4 lines
Quoted 4 lines

Run:

sizeof(int) = 8, sizeof(*) = 8

^ ^
This should be both 4, I assume this happened due to -mint64.

Quoted 7 lines
Quoted 7 lines

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]

Quoted 4 lines
Quoted 1 line

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

#10 lore raw
Quoted 11 lines · Thiemo Seufer
Quoted 7 lines · Ralf Baechle
Quoted 5 lines · J. Scott Kasten

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.

Quoted 6 lines
Quoted 4 lines
Quoted 4 lines

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.

Quoted 8 lines
Quoted 5 lines
Quoted 5 lines

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.

#11 lore raw

J. Scott Kasten wrote:
[snip]

Quoted 6 lines
Quoted 2 lines

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.

Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines

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]

Quoted 2 lines

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

Are you a telepathic? :-)

Quoted 24 lines
        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)
Quoted 3 lines

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

#12 lore raw
In reply to J. Scott Kasten
Quoted 14 lines · J. Scott Kasten
    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)
Quoted 3 lines

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