Date: Sun, 9 Jan 2011 15:45:04 +0100 From: Tijl Coosemans <tijl@freebsd.org> To: Juli Mallett <jmallett@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r217147 - in head/sys: amd64/include arm/include i386/include ia64/include mips/include powerpc/include sparc64/include sun4v/include Message-ID: <201101091545.11754.tijl@freebsd.org> In-Reply-To: <AANLkTimE7WPKJGp6CAv9rqPDanitTcQ0XG%2BXvq9YTskZ@mail.gmail.com> References: <201101081243.p08Ch5vR092295@svn.freebsd.org> <AANLkTimE7WPKJGp6CAv9rqPDanitTcQ0XG%2BXvq9YTskZ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart5487643.9KjrX2DFoP Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Saturday 08 January 2011 21:30:49 Juli Mallett wrote: > On Sat, Jan 8, 2011 at 04:43, Tijl Coosemans <tijl@freebsd.org> wrote: >> Author: tijl >> Date: Sat Jan 8 12:43:05 2011 >> New Revision: 217147 >> URL: http://svn.freebsd.org/changeset/base/217147 >> >> Log: >> On mixed 32/64 bit architectures (mips, powerpc) use __LP64__ rather th= an >> architecture macros (__mips_n64, __powerpc64__) when 64 bit types (and >> corresponding macros) are different from 32 bit. [1] >=20 > I don't know why you didn't talk with MIPS people at all about these > changes. That they were reviewed by Bruce is very reassuring in > aesthetic terms, but that's hardly sufficient. >=20 > This and other changes have made it harder to support common MIPS > configurations and compilation options on FreeBSD. I'm glad you're at > least aware of n32 (as indicated in another message) and its > implications, but the use of ABI-specific names was deliberate. Have > you thought about -n32 with -mlong64? It isn't the same kind of dirty > hack as Bruce talks about when he talks about 64-bit longs on x86. >=20 > I understand that __LP64__ and the idea that there are two reasonable > ABIs most (one 32-bit and one 64-bit) is appealing, but it's not true. > In the case of PowerPC, it does look like they weren't ABI-specific > macros, but MIPS's were. If nothing else, you make MIPS headers more > inconsistent with themselves, where most of them are > ABI-conditionalized and now some are instead LP64-centric. >=20 > It seems like your end goal is probably consolidating these headers, > which I would like, too, but please attempt to allow for more > variation than just "longs are 32-bit and pointers are 32-bit, > otherwise longs are 64-bit and pointers are 64-bit." We're trying to > do the right thing with MIPS in terms of supporting multiple valid > ABIs on a single port, something which is a lot harder when people > restructure these critical headers without even asking us whether > there are any evident problems; even if 'make universe', for instance, > were enough, it leaves out some ABIs, and it certainly leaves out > future plans wrt ABIs. My main goal is to compile 32 bit code on amd64. To do that i386 and amd64 headers need to be merged as much as possible and I'm looking at mips and powerpc headers as examples. As I'm going through each of the machine headers however and as people review my patches several issues have come up. These are mostly generic in nature and spread over all architectures, not just mips. There are more problems in the mips and powerpc headers however because of the complexity of supporting both 32 bit and 64 bit ABIs. If you consider the mips headers too delicate to be changed without approval from mips@ I'll make sure to send patches there before committing from now on. As for 64 bit longs on 32 bit ABIs I would advise against spending your time on that. It's something that sounds nice in theory, but it's just not practical. You don't gain anything from it because there's another 64 bit type already (long long) and there's too much code out there that relies on long and pointer types having the same size or that assumes long is different between 32 bit and 64 bit ABIs, also in our own tree. So yes, in practice there's only ILP32 and LP64 and nothing in between. About the use of __LP64__. It's essentially cosmetic and can easily be changed back. However, if you can agree with me on mlong64 I would like to keep it (for type definitions). What the patches (committed + upcoming) show is that _inttypes.h, _limits.h and _stdint.h (_types.h needs more work) are exactly the same for mips, powerpc and x86 indicating that they aren't architecture specific. Changing __LP64__ back to __mips_n64 would introduce a difference that isn't any. Moreover, those headers would also work on pure ILP32 (arm) and LP64 (ia64, sparc64) architectures, so personally I would like to move them to sys/, because as the patches show, duplicated code starts to diverge, bugs creep in and are subsequently copy-pasted. Whenever I suggested this to someone however I never really got a positive response so the headers will stay under machine/ for now. I would still like to get a clear yes or no on this though. If you would still like to support mlong64, I think it should be possible to do this for all 32 bit architectures because the size of long isn't architecture dependent. But like I said, in my opinion it requires a lot of effort to get right for no gain at all. --nextPart5487643.9KjrX2DFoP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iF4EABEIAAYFAk0pyfcACgkQfoCS2CCgtisQCgD+JpivGdKHMVojasPXYx1EGp9C GUlYrc5W/4hPc1/F1UwA+gKN+8xgtQLPd4A+sqg41rNpGD7NeyuNUSYRA7zXij5w =c5kQ -----END PGP SIGNATURE----- --nextPart5487643.9KjrX2DFoP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101091545.11754.tijl>