Hello. 

Thanks for detailed information. Lot of things got
confirmed. Its also evident that the 64bit support
cannot be done single handedly. I guess people out
there are already working towards this.

> - We need to have 64bit toolchain first, which can
> produce N64 ABI
> and N32 ABI in full scale.   GCC side efforts
> unfinished and incomplete
> comparing to MIPS own compiler kit.
Yes if we have to support O32 and N32/64 we need a
toolchain. Plus I guess most of the apps *today* would
look for N32 support than N64. Atleast I'm still not
able to concieve an app requirement with 1T user
space^_^

However in the kernel I have, does contain ".set
mips32" and ".set mips64" pseudoes in one assembler
file. But the compiler I have, Mar 27 2002 build does
not support these directives. What are they??

It also occured to me that the Linux guys have MIPS64
support. Even the toolchains for them support N32 &
N64. I'm planning to try this build out. But I wonder
whether this effort will be worthwhile, and that I'll
be able to get 64bit (cross?) toolchain support for
NetBSD.

I'd be very much interested to evaluate/test such
toolchain if anybody is willing to share. 


> - You need to understand variations in MIPS ABIs. 
> It defines how
> processor's thirty-two registers are used in
> executables.  It's regrettable
> to understand ABI incompatibility of old-standard
> O32 which NetBSD
> relies on.  You already got Stweetman's book I
> guess.  Check and see
> Section 10.8 of page 274 to know what's wrong.
Yes it is very much clear that we must support N32/64
support while keeping all O32 apps alive. We could
leverage on a bit inside ELF header which tells if its
ABI file or not. 

> - It's expected to realize 64bit kernel which can
> run N32 and N64
> binaries as well as existing 32bit O32 binaries. 
> 64bit kernel would utilize
> 64bit pay load of every register while 1T user
> address space for N64
> applications (there is no particular reason to
> prevent the larger extent of
> R10000 if things were done correctly) .  For
> application compactness,
> N32 executables are practical.
> 
> - We need to have XTLB handler with the combination
> of 64bit pmap.c,
> which must be implemented from vacuum.  Never try to
> understand and
> correct the our 32bit pmap implementation.  It's not
> worth of fixing
> since ASID handling is quite broken...  L4/MIPS from
> southern hemisphere
> looks like promising technical source, but please
> keep in mind it's designed
> for single address space OS.
I think the XTLB handlers are already coded. Perhaps 
by changing other parts like pmap we'll be able to get
XTLB up. 

What are the opinions on this??

Many thanks.
Girish.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com