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