n32 support patches

[M. Warner Losh]

In message: <ed91d4a81003011230j1530188du445bcdd3ab0e19ce at mail.gmail.com>
            Artem Belevich <fbsdlist at src.cx> writes:
: n32 could be helpful when one has a lot of third-party code that's not
: 64-bit clean.

True, but not a huge concern with the FreeBSD kernel :)

: 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?

Also memory traffic bandwidth can be a problem, but that's closely
related to cache thrashing...

: 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

cool tricks...

BTW, I'm trying to pull together the various n32/n64 patches into
something to commit to the tree soon...  First stop will be the
toolchain.

Warner

: 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"
: >
: _______________________________________________
: 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"
: 
: