n32 support patches

[C. Jayachandran]

On Tue, Mar 2, 2010 at 10:07 AM, Juli Mallett <jmallett at freebsd.org> wrote:
> On Mon, Mar 1, 2010 at 20:08, C. Jayachandran <c.jayachandran at gmail.com> wrote:
>> On Tue, Mar 2, 2010 at 1:07 AM, Juli Mallett <jmallett at 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.  n32+64bit
>> phys will hopefully work out the next level of issues(TLB/page table
>> entries).  From 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.

My own experience with o64 (please see below on o64), was not as bad,
which is the main reason why I started on this path. I guess if n32
user-space will be supported, n32 tool-chain and compilation will have
to be supported, so n32 kernel is worth a shot, and not a distraction.

>> 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).  And 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.

I hope we can keep the trapframes same for n32 and n64 along with
other user-visible structures (have not fully looked at it yet).
Getting pointers to 64 bit increases your memory usage and cache foot
print.

>> 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.

o64 (http://gcc.gnu.org/projects/mipso64-abi.html) has 32 bit long and
32 bit pointers, but the registers, argument passing and stack
alignment is 64bit, so when used with mips64 architecture, you get to
use the 64bit registers and operations for 64 bit types (uint64_t and
int64_t), without having the footprint of LP64. But o64 is old (even
when they named it, it was old :) ) - and n32 gives the same results.

>> 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.

The default ddb seems to work on my n32 compilation of HEAD, with the
key sequence, I was sure the register_t is 64bit, I will have to look
at this then.....

Regards,
JC.