Re: standard runtime for (possible/hopeful) 64bit kernels

[Paul Koning <Paul_Koning%dell.com@localhost>]

>>>>> "Toru" == Toru Nishimura <locore64%alkyltechnology.com@localhost> writes:

 Toru> Paul Koning said;
 >> if you want 64 bit FP registers, then I agree N32 or N64 is the
 >> way to go.

 Toru> n64 was invented to explore 64bit nature of post-R4000
 Toru> processors; - to have more arguments in registers passed to
 Toru> callee.  - to have 64bit integers in 64bit GP registers.  -
 Toru> same as 64bit FP in 64bit FP registers.

O64 gives you one of these -- 64 bit integers in GP registers.  I
wonder how big a win the 8 argument registers are.  

 Toru> n32 is a particular variant of n64.  In kernel handling wise,
 Toru> the two are identical each other.  And processor mode runs in
 Toru> the same, including xtended TLB refill code path and the use fo
 Toru> XTLBASE register.  So, if NetBSD is going to have n64, n32 is
 Toru> realised instantly w/o any further work.

That sounds right.  N64 is the harder job because you have to fix all
the code that assumes sizeof(void *) == sizeof(int), and for that
matter code that assumes sizeof(long) == sizeof(int).  Done right, the
resulting code should work for N32 also.

You'd want to make sure N32 is an option for people who don't want the
space penalty of 64 bit pointers.

 >> For newer ABIs you need either a real FPU, or compile everything
 >> with -msoftfloat if you don't have an FPU.  That's fine; softfloat
 >> is faster and cleaner than FP emulation.

 Toru> Your point taken.

Given that lots of embedded apps make little use of the FPU (even if
there is one), I like O64 because it's much less work.  Note that O64
can do 64-bit pointers if you want that (with the -mlong64 switch to
GCC).

        paul

PS. Is port-mips a moderated list?  I don't see my posts.