From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 19:36:32 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C59F1065675; Wed, 18 Feb 2009 19:36:32 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id 64CA58FC19; Wed, 18 Feb 2009 19:36:32 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from jflores-gxdt755.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KFA00ME214TZA40@asmtp011.mac.com>; Wed, 18 Feb 2009 11:36:31 -0800 (PST) Message-id: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090218.120514.831271136.imp@bsdimp.com> Date: Wed, 18 Feb 2009 11:36:29 -0800 References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218.120514.831271136.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:36:33 -0000 On Feb 18, 2009, at 11:05 AM, M. Warner Losh wrote: > : In other words: by tweaking the alignment of 64-bit types in > : n32, you prohibit GCC from using the 64-bit capabilities of > : the processor and MIPS isn't so weird anymore. > > I think so, but there's a twist. > > On MIPS, one kernel supports multiple ABIs at the same time. I'm not > entirely sure how the routing interface would cope with this sort of > thing because the size of u_long changes. I need to do some more > research to see what's going on there... Hmm... My first reaction is not to go there right away. It's probably safer or go the amd64 route: keep ILP32 and LP64 distinct. We have the infrastructure in place and we can always optimize and blend once things are working. > There are other ABIs on ARM that don't suffer from these problems. We > should investigate using them. I agree. It's better for FreeBSD/arm in particular if it's more like FreeBSD/i386. It may not be best for the ARM port in absolute sense, but we only have a few developers working on non-i386 hardware and a whole lot of developers who don't care about non-i386... > : The point being that programmers *do* code with certain > : assumptions and as soon as those assumptions don't hold on > : a platform, you end up worse off. My thoughts for MIPS n32 > : are to make it behave like any "normal" 32-bit strong- > : alignment platform to avoid 1) a large number of runtime > : alignment faults -- which are a bigger performance bottleneck > : than forcing 64-bit integrals to be accessed with 2 32-bit > : accesses > > Run time faults aren't a bottleneck. They are a core dump, which is > why I'm looking at this in the first place. :) :-) > : At Juniper I changed the ARM compiler default by adding: > : -mstructure-size-boundary=8 > : > : That made life a *lot* simpler and performance hasn't been > : sacrificed. > > Except you've invented a new ABI by doing that... We have a products to make and a source base to work with. Swimming upstream is best left to salmons :-) > I think that the > project should look at transitioning to a different ABI that works > better. ARM has several to choose from... I tend to agree. > It also turns out that in this case, a simple (void *) is safe and > causes no issues because that time_t isn't accessed... It does give > one time to pause and think about it. Fair enough. Misalignment in process space can easily be made non-fatal, in which case it's mostly a performance problem. That makes the problem space much more contained and therefore easier to deal with... -- Marcel Moolenaar xcllnt@mac.com