Hi again,
On Tue, 2007-11-06 at 21:10 +0000, Thiemo Seufer wrote:
> Christian Holm Christensen wrote:
> > Hi Thiemo,
> >
> > On Tue, 2007-11-06 at 18:56 +0000, Thiemo Seufer wrote:
> > > Christian Holm Christensen wrote:
> > > > Hi Thiemo,
> > > >
> > > > On Mon, 2007-11-05 at 00:48 +0000, Debian Bug Tracking System wrote:
...
> > > I notice that the regex in configure excludes now mipsel.
> >
> > I did that because I wasn't sure if it would work on mipsel straight out
> > of the box, since the endianess is important for I/O among other
> > things.
>
> The places where endianness is visible would need some care, true.
> The compiler provides built-in macros for that purpose:
>
> __MIPSEL__ for little endian
> __MIPSEB__ for big endian
> I presume you already use a macro to select endianness, selecting it
> via the compiler builtins should be straightforward.
Currently, there's the following code in ROOT to deal with Linux on
mips:
#if defined(linux) && defined(__mips)
# define R__LINUX
# define R__UNIX
# define NEED_SIGJMP
# if defined(__mips64) || defined(_ABI64)
# define R__B64 /* enable when 64 bit machine */
# endif
# if !defined(__MIPSEB__) /* Little endian */
# define R__BYTESWAP
# endif
#endif
> > > The only
> > > difference between both is the endianness. For complete MIPS support
> > > it would need the following:
> > >
> > > mips O32 ABI, ILP32, "long long" in a "aligned" even-odd register
> > > mipsel pair, 4 argument registers
> > >
> > > mipsn32el N32 ABI, ILP32, but with 64 bit wide registers, and
> > > mipsn32 "long long" in a single register, 8 argument registers
> > >
> > > mips64el N64 ABI, LP64, 8 argument registers
> > > mips64
> >
> > I'm not sure how to understand your table. Could you, along the lines
> > outlined at
> >
> >
http://wiki.debian.org/DebianScienceROOT -> Porting Notes
> >
> > tell me what changes would be needed? Perhaps which already support
> > registers the 6 cases above would be similar to?
Just to make sure: There are only two Debian MIPS architectures: mips
and mipsel. Does that mean, that
Debian arch | ABI (from your list above)
-------------+---------------------------
mips | mips, mipsn32, mips64
mipsel | mipsel, mipsn32el, mips64el
> > I guess the O32/N32/N64 is the "word-size", but what is the "O" and
> > "N"?
> >
> > I don't know what you mean by ILP32/LP63. I also don't know how to deal
> > with "long long" in 1 or 2 registers.
>
> Sorry, I realize that was too terse. O32/N32/N64 are the names of the
> ABIs (Application Binary Interfaces) supported on Linux/MIPS.
Ah, I see.
> I attempted to add a short outline of its properties to each mention.
>
> ILP32 is a common abbreviation for an ABI with "32bit integer,
> 32bit long, 32bit pointer size", describing the most important
> C types. This is like classic Linux i386. The comparable MIPS
> ABI is O32.
>
> LP64 is a shorthand for "64bit long, 64bit pointer size". This
> is what most 64bit Unices use, one example is Linux AMD64. The
> comparable MIPS ABI is N64.
>
> The N32 ABI is a bit odd, it combines a 32bit address space with
> 64bit wide registers, but it still retains the classic (ILP32)
> data type lengths. I mentioned "long long" since that is the only
> data type which is subtly different between both ILP32 variants.
> Maybe this part isn't relevant for ROOT.
I guess whether the O32/N32 split is important, depends on where "64bit
wide registers" registers are used and important.
> > I guess the "argument registers" refers to variadic arguments, but
> > exactly what that would imply in the ROOT source code I don't know.
>
> On MIPS (and most other RISC-like architectures) the first few
> arguments to a function are passed via registers. From the
> powerpc code in cint I inferred this is an important property
> which the code needs to know about.
The code in CINT related to MIPS is currently
#elif (defined(__mips)&&defined(linux))
/**********************************************
* MIPS, Linux
**********************************************/
# define G__VAARG_INC_COPY_N 4
# define G__VAARG_PASS_BY_REFERENCE 8
I guess these should really be
| mips | mipsn32 | mips64
| mipsel | mipsn32el | mips64el
---------------------------+--------+---------------------
G__VAARG_INC_COPY_N | 4 | 8 | 8
G__VAARG_PASS_BY_REFERENCE | 4 | 8 | 8
if "G__VAARG_INC_COPY_N" is meant to be the size of the argument
registers, and "G__VAARG_PASS_BY_REFERENCE" is the number of arguments
passed by reference through registers. Can someone on the CINT mailing
list elaborate please? Thanks.
How would one find out whether the ABI was O32 or N32? Is there some
pre-processor macro that will tell you? I guess the code quoted above
will be enough to distinguish between mips/mipsn32 and mips64, but it's
not clear how I would distinguish between mips and mipsn32.
> > I've Cc'ed this mail to rootdev and cintdev for more input.
> >
> > > Note that the "el" is always the suffix.
> >
> > OK. That goes for the return from `uname'?
>
> Not quite. The uname is on a 32bit kernel "MIPS", and on a 64bit kernel
> "MIPS64", regardless of endianness. You may have noticed by now that I
> say "ABI" and try to avoid "Machine" or "CPU", since those are not
> necessarily identical things. 'uname' would return the wrong result
> if we want to build a 32bit program on a 64bit capable machine.
The ROOT configure script uses the triplet
arch=`uname -s | tr '[A-Z]' '[a-z]'`
chip=`uname -m | tr '[A-Z]' '[a-z]'`
rele=`uname -r`
to figure out the "platform" we're compiling fore - can I some how, from
that triplet - figure out which ABI we're using?
On the other hand, I don't think I need to do much based on the
endianness since that's dealt with in the code directly. OK, there may
be a need to define a separate "mips64" "platform", since some compiler
flags are specific to the word size.
I get the feeling that you have code compiled on O32, N32, and N64
intermixed in the "mips" and "mipsel" distribution - which sort of
implies that all chips can handle this. However, I'm not sure I
understood this correctly. Could you tell me a little bit about why
there isn't separate mips, mipsel, mips64, and mips64el distributions?
Thanks.
> In Debian the selection is handled via dpkg-architecture, which tells
> exactly what build type is asked for.
I'd rather have the ROOT configure script properly discover the right
thing than to code it into debian/rules. Of course, if all else
fails ... :-)
> For other Distributions the best practice is to combine uname output
> with a test for predefined compiler macros to figure out the default
> endianness, and hope the result is what was asked for.
:-)
> > > Builds fine on mips/experimental.
> >
> > Great. Could you make the packages publicly available? If so, I'll
> > upload them to the above repository.
>
> Will soon show up at
http://people.debian.org/~ths/root-system/mips/OK. I will grab them soon :-) Thanks.
Yours,
--
___ | Christian Holm Christensen
|_| | -------------------------------------------------------------
| | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91
_| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91
_| Denmark Office: (+45) 353 25 404
____| Email:
cholm@... Web: www.nbi.dk/~cholm
| |
