Hi Thiemo,
First off, thank you for your detailed answers.
On Wed, 2007-11-07 at 02:44 +0000, Thiemo Seufer wrote:
> Christian Holm Christensen wrote:
> > 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.
>From your mails, I gather that it would be OK to assume that mips and
mipsel are the same (Endianness is handled directly in the code).
...
> > Currently, there's the following code in ROOT to deal with Linux on
> > mips:
> >
> > #if defined(linux) && defined(__mips)
>
> Better would be to check for __linux__ and __mips__. linux might be a
> variable in the code somewhere... The __mips__ version with two trailing
> underscores is the more common one. So:
>
> #if defined(__linux__) && defined(__mips__)
OK, thanks.
> > # define R__LINUX
> > # define R__UNIX
> > # define NEED_SIGJMP
> > # if defined(__mips64) || defined(_ABI64)
>
> This is broken, as __mips64 is also defined for N32, and _ABI64 is always
> defined. Assuming the R__B64 controls both address space and register size,
> it should be:
>
> # if _MIPS_SIM==_ABI64
Ah, I see. Ok thanks.
> I don't know what the exact semantics of those defines are, and how well
> suilted they are to support N32.
>
> > # define R__B64 /* enable when 64 bit machine */
> > # endif
> > # if !defined(__MIPSEB__) /* Little endian */
>
> For more clarity:
>
> # if defined(__MIPSEL__) /* Little endian */
Right.
> > # 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
> > > >
...
> > 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
>
> No, sorry again for leaving ot crucial information. Debian currently
> supports only O32 ABI. Support for the other ABIs is planned in future
> but so far hasn't progressed much beyond 64bit Kernels. The ABI names
> quoted above are actually the propsed Debian architecture names, since
> "Debian architecture" effectiely means "support for one specific ABI".
No worries, and thank you for the clearification.
> > 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.
>
> Sounds like it, yes.
OK, fixed.
> > 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.
>
> For O32:
>
> #if _MIPS_SIM==_ABIO32
> ...
> #endif
>
>
> For N32:
>
> #if _MIPS_SIM==_ABIN32
> ...
> #endif
>
>
> For N64:
>
> #if _MIPS_SIM==_ABI64
> ...
> #endif
Very nice, thank you.
...
> > 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?
>
> As I tried to explain, no. You can see the same problem already on a
> AMD64 machine when trying to compile 32-bit code (via gcc -m32).
> Using uname to figure out the ABI is inherently broken for multi-ABI
> environments. It only allows to do better guesswork.
Ah, now I get it. Thanks.
> Current best practice in Debian is to feed dpkg-architecture values
> to configure, this also makes cross-building via dpkg-cross possible.
Hmm. ROOT does not use Autotools (even though it may look like it), so
special "translations" has to be set up - quite a hassle and error
prone. That's why I prefer a solid detection in "configure" directly.
> > 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.
>
> Endianness should work out mostly automatically. For compiler flags,
> the MIPS gcc uses -mabi=32, -mabi=n32, -mabi=64 to select the right
> thing. So it would be three different platforms in the end.
Great. Thanks.
> > 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.
>
> It's a bit more complex. MIPS spans probably the largest performance
> range of any CPU family, from a 32bit 20 MHz Microcontroller (made by
> Microchip) up to a 64bit monster with over 5000 CPUs (made by SiCortex).
> Obviously, only the 64bit CPUs can run 64bit code, but 32bit code runs
> on all of them.
>
> The use cases for the different ABIs are:
> - O32: Most compatible, runs everywhere
> - N32: Best performance on 64 bit if a large address space isn't needed.
> It is faster than O32 due to improved calling conventions, and it
> is faster than N64 due to reduced pointer size.
> - N64: Huge address space.
Ah, I see. So the safe bet is to use "-mabi=32" everywhere :-)
> > 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.
>
> They are supposed to be eventually separate, but co-installable in the
> multiarch framework. For now, Debian has only mips/mipsel, and some
> 64bit capable kernels. The next step is to provide 64bit libraries
> inside the existing mips/mipsel distribution.
>
> I hope this gave some more insight.
Very much more so - thank you very much - quite instructive and
informative. Excellent comments.
Just one question: Is it possible for you to try to build the packages
on mipsel?
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: [EMAIL PROTECTED] Web: www.nbi.dk/~cholm
| |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
