Date: Mon, 1 Mar 2010 20:37:54 -0800 From: Juli Mallett <jmallett@FreeBSD.org> To: "C. Jayachandran" <c.jayachandran@gmail.com> Cc: freebsd-mips@freebsd.org Subject: Re: n32 support patches Message-ID: <eaa228be1003012037i783b1ea6nd9a1dfe2ce432f0b@mail.gmail.com> In-Reply-To: <98a59be81003012008y5b294094mc7139dd96836fa04@mail.gmail.com> References: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> <eaa228be1003011137y62980f9dl1fb389825c36aeef@mail.gmail.com> <98a59be81003012008y5b294094mc7139dd96836fa04@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 1, 2010 at 20:08, C. Jayachandran <c.jayachandran@gmail.com> wr= ote: > On Tue, Mar 2, 2010 at 1:07 AM, Juli Mallett <jmallett@freebsd.org> wrote= : > My own final target is to have n64 support for XLR - I see n32 is just > a first useful step in that direction. But I think the easiest way is > to go n32 -> n32+64bit phys -> n64. It's easy, but I don't think much of the work is actually transferable besides trivial stuff like syscall args. > The first step n32 will work out the ABI issues as it is very similar > to n64. A lot of the initial kernel changes (for 64 bit registers, ABI > support for system calls and signal handling) and user-space (ABI > support for system call/ld.so etc) can be worked out here. =A0n32+64bit > phys will hopefully work out the next level of issues(TLB/page table > entries). =A0From there n64 will be getting the 64bit pmap and working > out 64-bit compilation. There's no reason you can't run n64 with 32-bit addresses and old pmap, you just have to sign extent -- no problem. I have an n64 kernel from my branch that gets as far as the first call to pmap_map(), but it blows up, I believe, due to brokenness of the segmap macros and shifts. Suddenly 0xc..... becomes 0xffffffffc.... and there's a lot more to index into the segmap. Easy to fix, but I'm spending my effort on n32 right now because I have an immediate deadline. I think that n32 is so degenerate (registers > pointers) that it actually breaks a lot of things elsewhere in the system. See my commits to DDB on my branch to deal with db_expr_t fallout, for example. n64 is standard LP64 and much less likely to be broken. A lot of n32 effort is spent on the degenerate cases that don't actually apply to n64 since, for example, long is the size of registers and pointers on n64. > Also I think it will be useful to have an advanced 32 bit option for > mips64 and better architectures. o32 is inefficient in processors > supporting mips64 instruction set (64 bit operations are split instead > of using 64 bit operations). =A0And some customers we talked to have > large amounts of probably-not-64-bit-clean source code, so a 32 bit > option is always useful. Do they actually want to run 32-bit code in the kernel? The differences between n32 and n64 aren't that great in the kernel except for memory usage for the stack and trapframes, so I'd hope performance wouldn't be the problem. Bad code that can't handle big longs and pointers is going to have huge problems in the kernel where there are many opportunities to shoot your foot off. > On the 64-bit registers and 32-bit pointers issues - RMI's initial > port was o64 and 64 bit physical addres We did not have many issues in > the main kernel. The intel PAE mode, which seems to be supported has a > similar setup (32bit with 64bit physical addr) was already supported > in kernel, so our effort was minimal here. o64 has 64-bit pointers, even if you're using the compatibility segments and sign extending (and, thus, using a ~32-bit pmap.) Symbols in ELF have only 32-bits, but the pointers are definitely 64-bits. > So overall, I think of n32 as a useful thing, and I don't think there > will be any additional code just for n32 because it should be a subset > of n64 support. That just isn't true unless you're going to (to pick the most grotesque example) have db_expr_t and the like be only 32-bits for n32, which is really bad because then ddb becomes pretty useless. Thanks, Juli.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eaa228be1003012037i783b1ea6nd9a1dfe2ce432f0b>