linux-mips
[Top] [All Lists]

Re: A question about architecture and byte order with RPMs

To: adevries@engsoc.carleton.ca (Alex deVries)
Subject: Re: A question about architecture and byte order with RPMs
From: ariel@oz.engr.sgi.com (Ariel Faigon)
Date: Thu, 4 Dec 1997 00:10:34 -0800 (PST)
Cc: linux@cthulhu.engr.sgi.com
In-reply-to: <Pine.LNX.3.95.971204003012.3395M-100000@lager.engsoc.carleton.ca> from "Alex deVries" at Dec 4, 97 00:31:05 am
Organization: Silicon Graphics Inc.
Reply-to: ariel@cthulhu.engr.sgi.com (Ariel Faigon)
Sender: owner-linux@cthulhu.engr.sgi.com
You are correct except the "mips" (big-endian) on SGI situation
it is even more complex :-)

Come gcc 2.8 and SGI/Linux could theoretically support
N32 (the newer MIPS 32-bit ABI) and N64 (64 bits)
Just like the IRIX native cc compiler.

Unlike the Alpha which has only one programming model
        sizeof(long) = sizeof(char *) = 8

--- cut and save ---
SGI has 2 programming models (source interpretation):

        1) 64 bit (aka N64 or 64)
           compiled using "cc -64"

                sizeof(long) = sizeof(char *) = 8
                sizeof(int) = 4

        2) Old 32-bits (aka o32) compiled using "cc -32"
                And
           New 32-bits (aka n32) compiled using "cc -n32"

                sizeof(long long) = 8
                sizeof(int) = sizeof(long) = sizeof(char *) = 4

Going into binaries: o32 and n32 are not the same, the code
generated by n32 uses more efficient calling conventions
and more registers and cannot run on old versions of the OS.
New hardware and versions of the OS can run all of them except
if your 'uname' says 'IRIX' and not 'IRIX64' it can compile
(but not run) N64 binaries.

The advantages of this is that the new models run faster
since they are utilizing the new hardware better, plus
that you don't need to make all the apps 64-bits when
only 1% of them actually need this (a big saving in code
and data size).

The disadvantage is complexity and confusion...
Once SGI/Linux becomes stable, if gcc 2.8 is out and stable
we could try and migrate to supporting n32 (the dynamic linker
should support it, and a new set of dynamic libraraies should
be built for this)

So on SGI RPM should probably be named:
        mips-<abi>.rpm

where <abi> is one of:
        o32
        n32
        64

Currently SGI/Linux is purely o32 since that is the only ABI
gcc 2.7.x knows about.  The downside is that it is less efficient
than what it could have been (not utilizing the R4xxx and up
processors really well).

--- cut and save ---


:
:
:Below is a message I sent off to the RPM development mailing list. The
:folks at RedHat said it was reasonable, but I just wanted to be sure that
:I got it right. Many of you understand MIPS architectures better than I,
:and we don't want to be making a mistake.
:
:Is the creation of a mipsel type reasonable?
:
:- Alex
:
:---------- Forwarded message ----------
:Date: Tue, 2 Dec 1997 11:34:54 -0500 (EST)
:From: Alex deVries <adevries@engsoc.carleton.ca>
:To: RPM-List <rpm-list@redhat.com>
:Subject: A question about architecture and byte order.
:
:
:I *think* there might be an issue with MIPS architecture RPMs, but I want
:to make sure I get things right.
:
:There are two branches of machines that have MIPS processors.  The first
:is little endian, and it contains things like Acer Pica and Mips Magnum.
:The second is big endian, and has things like my SGI Indy[1]. I'm unclear
:if there are some architectures that will run both.
:
:Now, the issue is that there aren't distinct architecture definitions for
:mips (big endian) and mipsel (little endian). They aren't binary
:compatible, so it does seem to me that there should be an entry like:
:
:arch_canon:    mipsel: mipsel  11
:
:in rpmrc. 
:
:Am I wrong on this?
:
:- Alex
:
:[1] *almost* running srpms of RedHat 5.
:
:
:      Alex deVries          Rent this space for a $5 donation 
:  System Administrator      to EngSoc per day.
:   The EngSoc Project       Send spam to spam@engsoc.carleton.ca.
:
:
:
:
:


-- 
Peace, Ariel

<Prev in Thread] Current Thread [Next in Thread>