IRIX Network Forums
Irix 6.5.22 patches (32 or 64bit?) - Printable Version

+- IRIX Network Forums (//forums.irixnet.org)
+-- Forum: SGI/MIPS (//forums.irixnet.org/forum-3.html)
+--- Forum: Beginners' Questions/Tips (//forums.irixnet.org/forum-6.html)
+--- Thread: Irix 6.5.22 patches (32 or 64bit?) (/thread-1691.html)


Irix 6.5.22 patches (32 or 64bit?) - marmotta - 12-08-2019

Hi, I have an Indigo2 r4400 Impact with Irix 6.5.22, now I have installed some patches and my Os is died.... :-( (Kernel panic!)

When I do the installation of the patches, I have two choices: 32 or 64bit, I select 64bit patches. The good choice is 32bit? The r4400 is not 64bit?

RE: Irix 6.5.22 patches (32 or 64bit?) - Raion - 12-08-2019

R4400 is a 64-bit processor, the kernel itself, not sure. You'd need to check the kernel itself.

RE: Irix 6.5.22 patches (32 or 64bit?) - jpstewart - 12-09-2019

The R4K systems definitely run 32-bit IRIX.  You need R8K or higher for the full 64-bit OS, IIRC.  I don't remember why....

Any easy way to check is with 'uname'.  It'll return 'IRIX' for 32-bit or 'IRIX64' for 64-bit systems.

RE: Irix 6.5.22 patches (32 or 64bit?) - marmotta - 12-09-2019

(12-09-2019, 12:57 AM)jpstewart Wrote:  The R4K systems definitely run 32-bit IRIX.  You need R8K or higher for the full 64-bit OS, IIRC.  I don't remember why....

Any easy way to check is with 'uname'.  It'll return 'IRIX' for 32-bit or 'IRIX64' for 64-bit systems.

Yes! With uname return IRIX, not IRIX64 :-(

RE: Irix 6.5.22 patches (32 or 64bit?) - jan-jaap - 12-09-2019

64bit is relative. Using the N32 ABI, the R4000 will process 64bits of data at a time, even when using 32bit pointers.

Using 64bit pointers on a system with a memory capacity limited to a couple of hundred MB is stupid. Don't forget, those double wide pointers eat up your RAM and CPU cache twice as fast. Binaries are larger and an N64 binary will run slower than an N32 binary.

FWIW: the Challenge/Onyx series run IRIX64, even with R4x00 CPUs.

RE: Irix 6.5.22 patches (32 or 64bit?) - marmotta - 12-09-2019

(12-09-2019, 12:54 PM)jan-jaap Wrote:  64bit is relative. Using the N32 ABI, the R4000 will process 64bits of data at a time, even when using 32bit pointers.

Using 64bit pointers on a system with a memory capacity limited to a couple of hundred MB is stupid. Don't forget, those double wide pointers eat up your RAM and CPU cache twice as fast. Binaries are larger and an N64 binary will run slower than an N32 binary.

FWIW: the Challenge/Onyx series run IRIX64, even with R4x00 CPUs.

Instead it is normal on Indigo2 Irix is 32bit? Software Manager detect the machine id and automatically select the correct kernel? Regardless of the processor?

RE: Irix 6.5.22 patches (32 or 64bit?) - jan-jaap - 12-09-2019

(12-09-2019, 01:45 PM)marmotta Wrote:  Instead it is normal on Indigo2 Irix is 32bit? Software Manager detect the machine id and automatically select the correct kernel? Regardless of the processor?
Yes.

Indigo2 R4400 is hardware IP22 and 'inst' (or software manager) will automatically install the correct (32 bit) kernel.
Indigo2 R8000 is hardware IP26, and the R10K Indigo2 is hardware IP28, and for these the 64bit kernel is installed.

All O2's are hardware IP32, and they all run a 32bit kernel, even if an R12K CPU is installed.

RE: Irix 6.5.22 patches (32 or 64bit?) - bjames - 12-09-2019

I always surprised when I found out that the O2 was a 32bit machine. I assumed all SGIs from that time were true 64bit machines.

RE: Irix 6.5.22 patches (32 or 64bit?) - jan-jaap - 12-10-2019

(12-09-2019, 11:02 PM)bjames Wrote:  I assumed all SGIs from that time were true 64bit machines.
Define 64bit machine. Maybe the name "N32" is misleading because it's a mix of 32bit pointers and 64bit data operations.

Using the N32 ABI, the O2 (and any other SGI with a CPU supporting MIPS IV) can operate on 64 bits of data at a time. It will not use 64bit pointers, but on a machine with 1GB max RAM capacity there is no point prefixing all addresses with 32 bits of zeros, right? It only eats up RAM, CPU cache and execution time. 

Consider this trivial program which multiplies two 64bit numbers:

Code:
#include <inttypes.h>
#include <stdio.h>

int main(void)
{
        uint64_t i=1234, j=5678;
        printf("1234 * 5678 = %llu\n", i * j);
        return 0;
}

Compile:

Code:
$ cc -Wall -n32 -S -o hello.s hello.c

The assembly includes these bits:

Code:
        addiu $6,$0,1234                #
        sd $6,0($sp)                    #  i

        addiu $5,$0,5678                #
        sd $5,8($sp)                    #  j

        ld $1,0($sp)                    #  i
        ld $2,8($sp)                    #  j
        dmultu $1,$2                    #

This assembly far from optimized, but it it were optimized it would skip the entire calculation Cool

The important one is the last instruction: dmultu

DMULTU Doubleword Multiply Unsigned

Description:(LO, HI)← rs× rt The 64-bit doubleword value in GPRrtis multiplied by the 64-bit value in GPRrs,treating both operands as unsigned values, to produce a 128-bit result.  The low-order64-bit doubleword of the result is placed into special register LO, and the high-order64-bit doubleword is placed into special register HI.

If you were to compile this code as mips I, or -32, you'll see that it doesn't use the multu instruction, but inserts a call to a special compiler support function __ll_mul() to do the multiplication instead, because there is no single instruction in that ABI that can do this.