I was originally planning on punting on the 64-bit option for the 64-bit 
pmaxes, and having the size of mips_reg_t be determined on a MACHINE basis.

Are there people who really want to spend time making r4K pmaxes run faster
by going to 64-bit bcopy's, etc?

Just making things big enough to handle both and doing the appropriate 
pieces in the trap handler sounds like a fine idea to me, as long as people
don't mind losing the stack space, but it means that things
like setjmp/longjmp become processor dependent which sounds kind of icky
to me.

I tried to set things up to minimize impact on the rest of the 
existing mips ports, and maximize sharing of code.  If people want more
radical changes, I think it would require significantly more thought,
effort, and coordinated testing.  

	-castor

On Sun, 6 Dec 1998, Jonathan Stone wrote:
> If i understand it properly, the intent is to use 64-bit registers,
> say in hand-tuned assembler (like bcopy).  So on a 64-bit mips, the
> kernel needs to save all 64 bits of the integer registers.
> 
> Should we do `struct frame' as a union with space for both 32-bit or
> 64-bit registers, with runtime code to do the appropriate casts?  if
> the trap-handling code saves the registers in the right width, that
> should all just work...
>