Date: Mon, 1 Mar 2010 12:30:19 -0800 From: Artem Belevich <fbsdlist@src.cx> To: Juli Mallett <jmallett@freebsd.org> Cc: freebsd-mips@freebsd.org Subject: Re: n32 support patches Message-ID: <ed91d4a81003011230j1530188du445bcdd3ab0e19ce@mail.gmail.com> In-Reply-To: <eaa228be1003011137y62980f9dl1fb389825c36aeef@mail.gmail.com> References: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> <eaa228be1003011137y62980f9dl1fb389825c36aeef@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
n32 could be helpful when one has a lot of third-party code that's not 64-bit clean. It may also be arguably a bit more efficient than n64 as 32-bit pointers would result in smaller structures and thus less cache thrashing. It's hard to tell, though whether the difference is large enough to be worth bothering with. Does anyone know of any benchmark results comparing n32 vs. n64? In any case, those are marginal factors. I do believe than n64 kernel is the way to go. BTW, Some of 64-bit inefficiencies can be mitigated with -msym32: http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=3DAttac= hFile&do=3Dget&target=3Dnew-tricks-mips-linux.pdf --Artem On Mon, Mar 1, 2010 at 11:37 AM, Juli Mallett <jmallett@freebsd.org> wrote: > On Mon, Mar 1, 2010 at 06:28, C. Jayachandran <c.jayachandran@gmail.com> = wrote: >> I'm in the process of getting n32 ABI support for the RMI processors. >> The plan is have n32 compiled kernel with 64-bit register_t and >> physaddr_t and 32 bit long and pointer types. > > Hi JC, > > I've been working on this too in my user/jmallett/octeon branch in > Subversion and have gotten past some of the problems you mention, but > not always in the cleanest of ways. =A0I switched to using the libgcc > softfloat implementation instead of the libc one, for example, and > have committed some changes from Warner to libc's abicalls support. =A0I > am currently running with a static root filesystem to track down some > bugs with syscalls (I think just the ones with lots of arguments, i.e. > the ones we need to do copyin to get; or maybe it's the bogus quad > stuff, I don't know yet =97 the day is young) before moving on to fixing > the problems with dynamic linking. =A0If there's any way to coordinate > our efforts and you'd like to, let me know! > > One thing I will say is that I've been talking with Warner and we > think that n32 kernels are probably a pretty bad idea =97 a lot of the > system depends on pointers being the same width as registers, etc. > Neither of us could really think of a case where you'd want an n32 > kernel instead of an n64 kernel except for the case where your > bootloader just can't handle ELF64, in which case a trampoline or an > n32/o32 loader which can load ELF64 seems more beneficial. =A0Do you > have a use case in mind, or is it just that n32 is an easier target > than n64? > > Thanks, > Juli. > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ed91d4a81003011230j1530188du445bcdd3ab0e19ce>