"GIRISH V. GULAWANI" <girishvg@yahoo.com> asked again;

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

They seem intended to tell assembler to compile certain extended
instructions correctly.   Donno why they can be compiled.

> I think the XTLB handlers are already coded. Perhaps 
> by changing other parts like pmap we'll be able to get
> XTLB up. 

It's half baked.  Full scale XTLB handler would be much more
complicated.

(One issue in my mind.  Most post-R4000 processors share
one PTEbase value between CONTEXT register and XCONTEXT
register.  This means it's hard to have independent PTE arrays (two
pmap designs parallel in 32bit TLB and 64 XTLB.  Some modern
post-R5000s can have two different PTEbase values in those registers).

I think there is no need to have arch/mips64/ directory.  When things
were well ironned out, a small number of files to be added or modified
to make NetBSD/mips64 possible. 
- pmap64.c
crafted from vacuum.  Covers 64bit address spaces for user and kernel.
N32 process is considered as a particular subset of this case.
- pmap.c
crafted from vacuum.  Intended for R3000 and Post-R4000 in 32bit mode.
Cannot cope with any 64bitness.  Note that MIPS32 processors belong here.
- Exception handlers in locore
- handful #ifdefs in trap.c

That's all.  Provided with well considered design, distinctions and differences
between 32 and 64 would be marginal or near-invisible in source codes.

Toru Nishimura/ALKYL Technology