n32 support patches

[Artem Belevich]

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=AttachFile&do=get&target=new-tricks-mips-linux.pdf

--Artem



On Mon, Mar 1, 2010 at 11:37 AM, Juli Mallett <jmallett at freebsd.org> wrote:
> On Mon, Mar 1, 2010 at 06:28, C. Jayachandran <c.jayachandran at 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.  I 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.  I
> 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 — the day is young) before moving on to fixing
> the problems with dynamic linking.  If 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 — 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.  Do you
> have a use case in mind, or is it just that n32 is an easier target
> than n64?
>
> Thanks,
> Juli.
> _______________________________________________
> freebsd-mips at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mips
> To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"
>