Date: Wed, 18 Feb 2009 11:36:29 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips Message-ID: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> In-Reply-To: <20090218.120514.831271136.imp@bsdimp.com> References: <B23797BE-91FB-4AE1-8370-E77D66ED05B6@mac.com> <20090217.235826.-1697751865.imp@bsdimp.com> <BE046876-F8EF-4269-9CD6-743483EC1869@mac.com> <20090218.120514.831271136.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?064E7F22-AF3D-432C-B5E3-F71A34AB24AC>