From owner-svn-src-all@FreeBSD.ORG Mon Jan 10 16:23:34 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36D2C106566C; Mon, 10 Jan 2011 16:23:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D92EB8FC12; Mon, 10 Jan 2011 16:23:33 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p0AGHgoL097069; Mon, 10 Jan 2011 09:17:42 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D2B3124.30800@bsdimp.com> Date: Mon, 10 Jan 2011 09:17:40 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: Tijl Coosemans References: <201101081243.p08Ch5vR092295@svn.freebsd.org> <201101091545.11754.tijl@freebsd.org> In-Reply-To: <201101091545.11754.tijl@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Juli Mallett , 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 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 16:23:34 -0000 On 01/09/2011 07:45, Tijl Coosemans wrote: > 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. Please do so. Mips' ABIs are complex enough for the experts to understand the subtle implications of, let alone someone who thinks they behave exactly like all the other APIs out there. While the assumption that they are the same is generally true, it isn't universally true since n32 makes a hash of a lot of assumptions around the edges. > 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. Except n32 is only mostly ILP32, not totally ILP32. ILP32 tends to imply, for example, 32-bit registers. I've had to fix some code in the tree that assumed ILP32 meant 32-bit registers and LP64 meant 64-bit registers. Hence my comments above about n32 being an oddball. Same goes for stack alignment: n32 has 64-bit stack alignment, while o32 (and most other ILP32 ABIs) have only 32-bit stack alignment requirements. > 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. Please change it back for now. The n32 support in the tree is mostly complete, but still has a few issues that I'm trying to iron out with Juli. Having more churn in this area makes it more difficult to sort things out (and patch if things are actually wrong). > 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. Create a sys/_foo.h. Have all those architectures include it. That gives you the best of both worlds: for those that can use the standard foo.h, we provide one. For the oddballs, or ones where the standard one doesn't match the warts of history or current innovation, they can be overriden to cope. Warner