kirchner@informatik.uni-kl.de (Reinhard Kirchner) (06/24/91)
Months ago when the first discussions about the new MIPS R4000 processor where held here people from MIPS stated ( if I remember well ) that they will cross the limit of 32 bit addresses and be able to address a 64 bit virtual address space. Now today I got a data sheet of the R4000 from IDT, and it does not only say anything about this, it also shows a block diagram with a 32 * 32 bit register set. So: will the R4000 really have 64 bit addresses and how can they be generated with 32 bit registers ? What comes into mind is just pairing them, to get 64 bit, but this would require extra instrucions, or a mode bit, and would in any case reduce the amount of usable registers considerably. Maybe people from MIPS ( Mr. Mashey ? ) could shed some light on this ? Reinhard Kirchner Univ. Kasierslautern, Germany kirchner@uklirb.informatik.uni-kl.de
cprice@mips.com (Charlie Price) (06/25/91)
In article <8083@uklirb.informatik.uni-kl.de> kirchner@informatik.uni-kl.de (Reinhard Kirchner) writes: > >Months ago when the first discussions about the new MIPS R4000 processor >where held here people from MIPS stated ( if I remember well ) that >they will cross the limit of 32 bit addresses and be able to address a >64 bit virtual address space. > >Now today I got a data sheet of the R4000 from IDT, and it does not only >say anything about this, it also shows a block diagram with a 32 * 32 bit >register set. So: will the R4000 really have 64 bit addresses and how >can they be generated with 32 bit registers ? > >Maybe people from MIPS ( Mr. Mashey ? ) could shed some light on this ? Since John Mashey is out of town... First, let me point out that the R4000 is not an announced product. Since the R4000 is NOT an announced product, there are details that we are not supposed to talk about. That means I can't give you a fully satisfying answer. Sorry about that. The R4000 has 32 registers -- each 64 bits wide, generates and tests 64-bit virtual addresses. The processor is able to execute existing 32-bit binary programs. If you are executing an existing binary (i.e. "being compatible"), your program will "see" registers and address space just like an R3000 -- 32 registers each 32-bits wide, virtual addresses 32 bits total with 31 bits for user space. The processor will also execute programs with virtual address spaces >32-bits that operate on 64-bit registers. 64-bit versus 32-bit operation is one of the areas that I can't talk about in detail. Sorry. -- Charlie Price cprice@mips.mips.com (408) 720-1700 MIPS Computer Systems / 928 Arques Ave. MS 1-03 / Sunnyvale, CA 94088-3650
mslater@cup.portal.com (Michael Z Slater) (06/26/91)
>Now today I got a data sheet of the R4000 from IDT, and it does not only >say anything about this, it also shows a block diagram with a 32 * 32 bit >register set. So: will the R4000 really have 64 bit addresses and how >can they be generated with 32 bit registers ? It seems that MIPS has been keeping a tight lid on the 64-bit details, and the initial product details will describe only the 32-bit subset of the chip. This is going to create lots of confusion, especially since MIPS has hyped the value of the 64-bit architecture. Michael Slater, Microprocessor Report mslater@cup.portal.com
sritacco@hpdmd48.boi.hp.com (Steve Ritacco) (06/26/91)
From what I know about the R3000, the only integer unit instruction affected by 64-bit operation would be the shift instructions which only have a 5 bit field for shift amount. Clearly you would have to use the register varient of the shift instructions, but other than that all the instructions would work for 32 or 64 bit opperands. I'm under the impression that the instruction set was layed out for minimal affect on word size.
paul@taniwha.UUCP (Paul Campbell) (06/27/91)
In article <14900025@hpdmd48.boi.hp.com> sritacco@hpdmd48.boi.hp.com (Steve Ritacco) writes: >From what I know about the R3000, the only integer unit instruction affected >by 64-bit operation would be the shift instructions which only have a 5 bit >field for shift amount. Clearly you would have to use the register varient >of the shift instructions, but other than that all the instructions would work >for 32 or 64 bit opperands. I'm under the impression that the instruction >set was layed out for minimal affect on word size. What about add/sub instructions - they trap on overflow, also any compare instruction that tests the sign bit - one solution for this might be for the 32-bit instructions to use the high 32-bits of a register (you would need new load/store instructions), or you could have a 64-bit/32-bit flag that puts the CPU into a particular mode (hopefully there would be one each for user/supervisor modes) Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P Tom Metzger's White Ayrian Resistance has been enjoined to stop selling Nazi Bart Simpson t-shirts - Tom of course got it wrong, Bart is yellow, not white.
meissner@osf.org (Michael Meissner) (06/28/91)
In article <880@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: | In article <14900025@hpdmd48.boi.hp.com> sritacco@hpdmd48.boi.hp.com (Steve Ritacco) writes: | >From what I know about the R3000, the only integer unit instruction affected | >by 64-bit operation would be the shift instructions which only have a 5 bit | >field for shift amount. Clearly you would have to use the register varient | >of the shift instructions, but other than that all the instructions would work | >for 32 or 64 bit opperands. I'm under the impression that the instruction | >set was layed out for minimal affect on word size. | | What about add/sub instructions - they trap on overflow, also any compare | instruction that tests the sign bit - one solution for this might be | for the 32-bit instructions to use the high 32-bits of a register | (you would need new load/store instructions), or you could have a | 64-bit/32-bit flag that puts the CPU into a particular mode (hopefully | there would be one each for user/supervisor modes) The other thing I've thought about is how do you do generalized external references. On the current R[236]000's a normal (non-GP) reference is two instructions: lui $at,addr>>16 <lw/sw> <reg>,addr&0xffff($at) I wonder whether we will need four instructions in the 64 bit universe. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 You are in a twisty little passage of standards, all conflicting.
jfc@athena.mit.edu (John F Carr) (06/29/91)
In article <MEISSNER.91Jun28105156@tiktok.osf.org> meissner@osf.org (Michael Meissner) writes: >The other thing I've thought about is how do you do generalized >external references. On the current R[236]000's a normal (non-GP) >reference is two instructions: > > lui $at,addr>>16 > <lw/sw> <reg>,addr&0xffff($at) > >I wonder whether we will need four instructions in the 64 bit >universe. I think a better way to handle 64 bit addressing is to do what IBM does on its (32 bit) RISC machines. Each function has a block of data containing the addresses of all external objects referenced by the function. The function caller loads a register with the address of this data area (having the caller load the register makes shared libraries and dynamic loading easier to implement). C code like extern int x; x = 4; compiles to (on the RS/6000) l r3,0x4(r2) # 4(r2) is &x lil r0,0x4 st r0,0x0(r3) This method takes 2 fewer instructions for a 64 bit address but adds a memory reference. I don't know how many MIPS opcodes are unused -- is there room to add two more instructions with format reg,reg,disp16? If not you'll need more than 4 instructions to load an address using the current method. -- John Carr (jfc@athena.mit.edu)
William.Lott@cs.cmu.edu (07/01/91)
jfc@athena.mit.edu (John F Carr) writes: ... > l r3,0x4(r2) # 4(r2) is &x ... > I don't know how many MIPS opcodes are unused -- is there room to add two > more instructions with format reg,reg,disp16? If not you'll need more than > 4 instructions to load an address using the current method. > > -- > John Carr (jfc@athena.mit.edu) Isn't that just an add? (Or, in the MIPS case, an ``addu?'') Why would you need additional instructions? -William Lott
William.Lott@cs.cmu.edu (07/01/91)
William.Lott@cs.cmu.edu writes: > jfc@athena.mit.edu (John F Carr) writes: > ... > > l r3,0x4(r2) # 4(r2) is &x > ... > > I don't know how many MIPS opcodes are unused -- is there room to add two > > more instructions with format reg,reg,disp16? If not you'll need more than > > 4 instructions to load an address using the current method. > > > > -- > > John Carr (jfc@athena.mit.edu) > > Isn't that just an add? (Or, in the MIPS case, an ``addu?'') Why > would you need additional instructions? > > -William Lott Oops. I guess I get the bozo award for the day. I had originally though that you were asserting that they needed an load-effective-address instruction, which is not needed, because it is just an addu. On re-reading your post, I realized the two needed instructions were load and store 64 bits. I don't have my MIPS R[23]000 book with me, but I'm pretty sure they have room for them. -William Lott