Note that both of these apply to pre-MIPS64 processors. In a MIPS64 implementation, The Status.PX bit should be used to enable 64-bit operations without enabling 64-bit addressing. The Status.XX bit is gone and can't be set. The addressing boundary condition that Bill mentioned is explicitly address in the Architecture for Programmer's manual, Volume III, section 4.10 as a requirement for hardware in exactly this case. I realize that Loongson is a MIPS III processor where Bill's suggestion may apply, but it's not a general problem moving forward to MIPS64. /gmu --- Michael Uhler, Chief Technology Officer MIPS Technologies, Inc. Email: uhler AT mips.com 1225 Charleston Road Voice: (650)567-5025 FAX: (650)567-5225 Mountain View, CA 94043 > -----Original Message----- > From: Ralf Baechle [mailto:ralf@xxxxxxxxxxxxxx] > Sent: Wednesday, April 18, 2007 9:38 AM > To: Uhler, Mike > Cc: Fuxin Zhang; tiansm@xxxxxxxxxx; > linux-mips@xxxxxxxxxxxxxx; Fuxin Zhang > Subject: Re: [PATCH 3/16] Kconfig update for lemote fulong mini-PC > > 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=1445 2.59571.970106.514001%40liveoak.engr.sgi.com > > Ralf >
