On Mon, Jan 14, 2002 at 11:17:08AM +0000, Dominic Sweetman wrote: > o Very large virtual address spaces, using 64-bit pointer types. Actually I only implemented support for something like 0.5TB. As for supercomputing that's peanuts (Like five years ago a customer requested SGI to increase the per process size of the address space from 1TB, the limit of the R4000 to 16TB, the limit of R10000 class processors.) > o C "long" (and perhaps even "int") becomes 64-bit. We follow the MIPS ABI which uses 32-bit ints and 64-bit longs. > In such a 64-bit Linux system, though, you might still want to be able > to run 32-bit applications with 32-bit pointers, int and long - either > for compatibility or economy (32-bit data types make for a smaller > program). SGI do this in Irix: I don't know whether the 64-bit > Linux/MIPS systems got around to it. Yes. The environment provided however is slightly different. 32-bit software on the mips64 kernel is running with UX=1 thus 64-bit instructions are allowed. > There are other potentially useful combinations: > > o A Linux where all machine-supported integer data types are 32-bit, I don't want to support 32-bit char and short, sorry :-) > but capable of addressing physical memory outside of a 4Gbyte map. > (In practice, you need to use this kind of system to get outside of > a 512Mbyte map - so it's urgent). I'd be working on this right now if you'd not be bothering me with email ;-) > Ralf says he has done this: it could be done without using any > 64-bit operations, but it might be easier with them. There are still MIPS32 systems which don't support 64-bit operations just may have an address space of upto 36 bits. > o A system using 32-bit pointers and 'long' throughout, but with > support for 'long long' 64-bit integer data types in registers. > > o A system using 64-bit addressing within the kernel, but not for > applications. > > However, it's unlikely to make sense to do all of them! Correct. We may add support for the one or other code of these models over time. > > I suspect that this is very much a toolchain issue, as I don't think > > gcc will generate 64-bit addressing code. > > I suspect that the generic GNU toolchains are pretty buggy when you > switch on 64-bit MIPS operation; but it's bug-fixes which are needed, > not wholesale new features. Actually in the past somebody was doing paid work to get the combo g++ + SGI as + GNU ld to work for N32. Due to the similarity of N32 and N64 that already brought us quite a bit closer to N64 support. That still leaves alot of work including plenty of gas work. > Politics: MIPS Technologies' advocacy for their "MIPS32" instruction > set dialect in embedded systems means there are now some quite capable > MIPS CPUs (eg Alchemy's 500Mhz integrated CPUs) which don't have > 64-bit datapaths or arithmetic. So casual dependence on 64-bit > operations should probably be avoided. I'm doing the best to avoid that. Ralf
