Re: [PATCH 3/16] Kconfig update for lemote fulong mini-PC

[Ralf Baechle <ralf@linux-mips.org>]

On Wed, Apr 18, 2007 at 08:28:16AM -0700, Uhler, Mike wrote:

> > Yes. Most 64bit MIPS processors cannot access 64bit content 
> > of registers when it is in 32bit mode.
> 
> For clarity, there is no 32/64-bit mode in MIPS processors.  There is a
> mode in which 64-bit OPERATIONS are enabled (that is, those instructions
> which operate on the full width of the registers) - See the definition
> of 64-bit Operations Enable in the MIPS64 Architecture for Programmers,
> volume III.  Note that such operations are always enabled while the
> processor is running in Kernel Mode.
> 
> The patch is a little short on context, but if you've got a 64-bit
> kernel, I had always assumed that save/restore of context is always done
> with LD/SD, not by figuring out whether a process has 64-bit operations
> enabled, then doing a conditional LD/SD or LW/SW.

Here's a funny one where we have something like a mode.  This is a
reposting from Bill Earl:

[...]
     One other issue is that UX should always be set, to allow use of
MIPS3 instructions, and that XX (bit 31) should be set on R5000 and
R10000 processors, to enable MIPS4 instructions.  This in turn means
that, to avoid various illegal address exceptions, the VM system
should not allow a 32-bit user program to map anything into the top 32
KB of the user address space.

     The problem has to do with some compilers using integer
arithmetic to compute a base for some variables in the current stack
frame, and then using negative displacements to address the variables,
for cases where the stack frame exceeds 32 KB, but is located near the
top of memory.  The 32-bit unsigned integer add to, say, 0x7fffff00
(64-bit address 0x000000007fffff00) produces a signed 32-bit value
such as 0x80000f00, which is the 64-bit value 0xffffffff80000f00,
since all 32-bit values, signed or unsigned, are stored as 32-bit
signed values sign-extended to 64 bits.  When you do a load with a
negative offset of, say, -0x1000, you get an address
0xffffffff7fffff00, not 0x000000007fffff00.  With UX=0, this would be
fine, but, with UX=1 (to enable MIPS3 instructions), the above address
is illegal.  If the $sp is always at least 32 KB below the top of the
address space, this problem does not arise, since any such intermediate
pointer generated by the compiler will always be below 0x80000000.
[...]

The original posting is at http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=14452.59571.970106.514001%40liveoak.engr.sgi.com

  Ralf