Talk:MIPS architecture

MIPS syscalls?

You speak about MIPS syscall... But are you sure they aren't SPIM syscall? Has the processor predefined syscalls???

I'm not sure what your question is. SYSCALL is an instruction implemented by the hardware. It would be used by the Operating System with different hint codes to call the relevant system call software. Since SPIM is a software emulator/simulator of the hw architecture, it would/should implement this instruction. Dyl 17:29, 28 September 2006 (UTC)

I'm speaking about the table entitled "MIPS system calls". It seems strange to me that MIPS has fixed system calls for print_int (1) or print_string (4).

Ah, sorry about my misunderstanding. MIPS didn't fix the system calls. These values are probably what's used by some OS kernel implemented on MIPS CPUs. That emulator just chose to copy what a particular OS does. If you implement both the kernel and the compilers/assemblers, you can pick your own values. Dyl 15:58, 30 September 2006 (UTC)

So may be we should rename the table. Something like "examples of MIPS system calls" or remove it ...

Major designers and contributors

It would be nice to list some major designers and contributors.

I have imperfect knowledge about this. Craig Hansen was the initial architect. Ed Hudson, John Moussouris, Tom Riordan, Chris Rowen, and Dan Freitas are often listed as some of the main implementors in the early days. Dyl 17:29, 28 September 2006 (UTC)

Influence on SPARC

I'd like to question the influence on SPARC. There were three RISC designs very early, that were demonstrations of the technology.

1. The IBM effort under John Cocke. This was virtually unknown outside IBM until much, much later, but may have been the inspiration for IBM projects including ROMP, Power, and PowerPC.
2. The Berkeley RISC project. An academic project that was probably the main inspiration for SPARC.
3. The Stanford project. An academic project that was definitely the main inspiration for the commercial MIPS RISC.

SPARC and (commercial) MIPS were developed at much the same time so it is unlikely that commercial MIPS had much influence on SPARC. The original Stanford chip was a bit older than SPARC, and the SPARC people were certainly aware of it, but in looking at the major differences between Stanford and Berkeley RISC (sliding register window only in Berkeley, and not much else) SPARC follows the Berkeley model.

Marice Wilkes states (in the foreword to Patterson/Hennessy) that MIPS is more-or-less the Stanford RISC project while SPARC is the commercialised Berkeley RISC. I therefore reformulated the sentence so that both are credited with influencing later RISCs. --Robbe

Microprocessor support in R3000

The microprocessor support in the R3000 may have been flawed (I don't really know), but it was NOT generally unused. SGI produced a very popular range of high performance graphics workstations featuring multiple R3000s (the 4D 2x0, 4D/3x0 and 4D/4x0 series) and SGI was far and away MIPS' largest buyer at that point (1990-1993). I also know that Ardent produced a four processor R3000 machine (the Ardent Titan 3000). I am loathe to admit it but DEC did too. The 58x0 series was shameful—DEC didn't really have a fast enough bus for four R3000s, let alone two, so the machines literally got slower as you added more CPUs. Not to mention that the whole thing relied on a VAX processor for the ROM.

Surely you mean 'multiprocessor'? However, I would like to know some more about this, does anyone have any external links where the supposed flaws are explained? Pipatron 10:17, 30 November 2006 (UTC)

Question: What is the `flaw' of R3000 multiprocessor support? The content in the article doesn't elaborate it. Is it about atomic operation? Lack of ll/sc support? —Preceding unsigned comment added by 220.135.250.105 (talk) 07:55, 14 November 2008 (UTC)

Use in TiVo

I believe the Series II TiVo's use MIPS and that's likely a high enough profile use to warrant a mention.

MDMX not clear

If MDMX is an integer SIMD instruction set why does it use 64-bit floating point registers ? Please make it clear in the text. --Hdante 9 July 2005 06:16 (UTC)

The idea was that if you were dealing with digital media code, it's unlikely you would be doing floating-point at the same time. MDMX was a cheap way of adding media operations without changing the compilers much (adding a new register set). In the long run, this wasn't too popular nor aggressive enough. Dyl 17:29, 28 September 2006 (UTC)

Sort of biased, but…

The article tends to be pretty pro-MIPS without putting it in the context of what other chips have been its contemporaries; for instance, it doesn't mention the ARM architecture at all - and I'd be more than a little surprised to hear that the two arches didn't have comparable numbers of devices out there. (I suspect that there's more ARMs, actually.)

There's also the inconsistently-applied moniker MIPS itself; for instance, while the Sony Playstation does have an actual MIPS Technololgies CPU, the PS2's core has an R5900 made by Toshiba. I think it might be a good idea to separately delineate the mips model (e.g. the R1000) from the mips architecture (e.g. MIPS32.) --moof 12:51, 26 March 2006 (UTC)

I think the level of boosterism is at the same level on the ARM article. That article doesn't mention other architecture neither. eg. A little architecture from Intel/AMD or low-end microcontrollers . Besides, neither article is trying to quantify the volume leaders (which ARM would currently win). Dyl 02:36, 7 April 2006 (UTC)

I wrote a substantial portion of the article, and did so basically in isolation of articles on the other designs noted above. This was really a function of the way I wrote the article; I simply gathered references about the topic, and wrote.

I can understand, in retrospect, why this would end up with a somewhat myopic view. I hope I don't go too far by suggesting that if you had access to information on only one thing, anything from apples to chipsets, it's likely that any article created from those sources alone would likely end up that way.

So, I'd be happy to hear from a few other people too, is this article too tightly focused on MIPS, to the point where it seems like boosterism? And it's not the first time someone has mentioned this about an article I was prime on, which is the basis for my concern. Maury 21:16, 9 June 2006 (UTC)

Instruction Set Summary

The article uses the non-standard term of CONST, while all MIPS official documentation uses the term IMMEDIATE. Using the official term would be better IMHO. Dyl 15:37, 2 May 2006 (UTC)

Influence on later RISC ISAs

I've just WP:BOLDly changed the last sentence of the Lede section from

The design of the MIPS CPU family, together with SPARC, another early RISC architecture, greatly influenced later RISC designs like DEC Alpha.

to:

The design of the MIPS CPU family greatly influenced later RISC architectures such as DEC Alpha.

Why? Our DEC Alpha article says (quite rightly, I believe) that the Alpha was indeed greatly influenced by MIPS, but does not mention SPARC. I'd guess that the Power Architecture was influenced by MIPS to at least some extent, but not much by SPARC. The only later architecture which could be regarded as showing much SPARC influence is IA-64, and there's a good case that IA-64 is not a RISC architecture; my "such as DEC Alpha" wording is intended to avoid that issue.

This is a lot of fuss over a small issue, but I've done it anyway. Cheers, CWC(talk) 08:28, 29 September 2006 (UTC)

Trivia

Regarding the recent edit to the Trivia section, I'm of the opinion that the piece of information doesn't belong here; rather, it belongs with the information for the Mips character, which can be found at Super Mario 64; the note about the connection between Mips the rabbit and MIPS the processor architecture is found there. Wikipedia:Trivia indicates it would be more appropriate there, too. This is why I removed the section a second time. – Mipadi 12:26, 18 October 2006 (UTC)

VPEs, TCs, ...

[1] DDJ article, "Multi-core Performance In Single-Core Using Multi-threaded Virtual Multiprocessors" -- Robocoder (t|c) 19:04, 10 December 2006 (UTC)

Opcode format unclear

There's a table with the opcode format and register numbers "rt", "rs" and "rd", but there is no explanation what these registers actually are. I suspect that "rt" is the target register of an instruction, "rs" is the source and "rd" an additional data register. —The preceding unsigned comment was added by 131.234.158.246 (talk) 13:25, 20 February 2007 (UTC).

It's pretty unclear in the MIPS manual too. They're supposedly "source", "destination" and "target". rt can behave as a source or destination depending on the instruction. Unfortunately there's a few instructions which just do whatever they feel like - like mfc0, which reads from rd and writes to rt. I think it's best to treat them as arbitrary labels. Asuffield 14:43, 20 February 2007 (UTC)

rd is destination, rs and rt are arguments. 128.163.7.129 17:20, 4 October 2007 (UTC)

Processor speeds

For the "MIPS microprocessor specifications" table, there is a note that differences in the amount of secondary cache can change (and certainly, 2Mb R12000s and 4Mb R14000s were common SGI configurations (on the Octane and Fuel respectively)) but also note that there were 900MHz R16000 Fuel and 4x1GHz R16000 Tezro variations - so 800MHz is certainly not the limit here!

87.112.6.190 19:36, 8 March 2007 (UTC)

Mipsel

Please add a definition for mipsel

NigelHorne 16:46, 30 March 2007 (UTC)

mipsel = MIPS, endian-little. mipseb = MIPS, endian-big. Letdorf (talk) 15:19, 25 August 2008 (UTC).

Free MIPS64 Simulator

Hello! I belong to a free (as in free speech) MIPS64 CPU Simulator development team. Do you think that it's acceptable to add the simulator's URL to the "External links" sections? The URL is http://www.edumips.org, the simulator's name is EduMIPS64. Thanks!

Delay slot

Why doesn't this article mention the delay slot, something somewhat unique to MIPS? -- Myria 17:38, 14 April 2007 (UTC)

I agree - my recollection is that the instruction after a branch is always executed and there must be a delay of one instruction between loading and using a register. These details were hidden even from assembly language programmers because the toolchain re-ordered instructions or inserted no-ops. This was therefore a precursor to out-of-order execution. -- Chris St John 15:54, 4 December 2007 —Preceding unsigned comment added by 62.254.208.197 (talk)

Yes. I always used ".set noreorder" in GNU "as" to disable this mode because I didn't like it. I think it's an important part of the MIPS architecture, and can help with optimizing for the platform. You can also do stupid things like absolute value in 2 instructions: bgtz a0, label \ label: \ subu a0, zero, a0 -- Myria (talk) 20:57, 15 December 2007 (UTC)

NEC

"The VR4181 microprocessor is the second NEC device to use the ultra-low power 66-MHz VR4110 CPU core based on advanced 0.25-micron technology. The VR4110 CPU has an optimized five-stage pipeline, 4-KB instruction cache, 4-KB data cache, multiply-and-accumulate (MAC) unit, and memory management unit that enable high performance in a compact, low-cost chip.

"The VR4181 microprocessor complies with the MIPS I, II, and III instruction set architectures (ISAs) and MIPS16 application-specific extension (ASE). The MIPS16 ASE compliance enables the VR4181 to incorporate 16-bit-long instruction format with conventional 32-bit-long instruction support, which results in compact code size, smaller memory foot print, and lower system cost."

If this article is not going to try to list all the MIPS-based cpu chips, there should be a linked WP article that does list and organize as many as possible.-69.87.203.47 13:14, 19 April 2007 (UTC)

Pipeline definition

As stated in the "History" (RISC Pioneer) chapter of the main article, MIPS' basic concept was related to that of pipeline, so I was thinking that maybe we should pay more attention to pipeline definition, or introduction, if it wasn't meant to give a proper definition here. (On a side note, I don't think the definition given on the instruction pipeline is very good either, I will try to persuade the community to change that one as well).

As is stands now, the article says: "Generally a pipeline spreads out the task of running an instruction into several steps, starting work on "step one" of an instruction before the preceding instruction is complete."

In my opinion this is not exactly what a pipeline does. Pipeline is not about one instruction (being executed in one go or in a few steps), but about overlapping the execution of a few instructions. The inherent parallelism (internal CPU modules working in parallel) is worth mentioning along with the fact that (and more important then) the traditional approaches "leaving large areas of the CPU idle".

I will come up with some modified first paragraph of "RISC Pioneer", but I wait to see what the general opinion is about this.
--Adsp 21:31, 16 May 2007 (UTC)

OK, what about this: "Generally in a pipeline architecture, successive instructions in a program sequence will overlap in execution. Modules inside CPU work in parallel so that CPU will load and start executing an instruction before the preceding instruction is complete. In contrast, traditional designs of the era waited to complete an entire instruction ''cycle'' before moving on, thereby leaving large areas of the CPU idle as the process continued.

--Adsp 13:49, 21 May 2007 (UTC)

Add Tandem Computers to list of manufacturers

I think that Tandem Computers should be added to the list of computer manufacturers listed under "loosing the desktop". For sure Tandem systems where not desktops :-) but I think that having been used in the NonStop fault tolerant architecture is an interesting piece of information related to the MIPS processors. --Apistore 14:31, 22 May 2007 (UTC)

R6000 did not deliver?

The article said "The R6000 did not deliver the promised performance benefits". This might not be true. The R6000 was very fast by the standards of the day (circa 1990 i think.) The big problem was delivering enough working chips. It used an exotic technology called ECL which ran hot and had problems with a high proportion of failed chips. I think there was no problem selling all the working chips they actually managed to get made. It was about as fast as the early R4000s that were not delivered until well after the R6000. In fact the R4000 designers used a R6000 for computationally intensive tasks in the design of the R4000. MIPS abandonned ECL after the R6000 experience and went back to CMOS for later chips. (All this from memory, as an outsider. I'm sure it was all public knowledge at the time, but maybe not published anywhere respectable.) 198.142.39.182 03:20, 7 June 2007 (UTC)

The R6000 sure did run fast when it ran, but finding a real-world running system with one was a bit of a trick :-) I do think that the "performance benefits" statement from the article could be rephrased, but it would be blatantly false to claim that the R6000 ran well. It (along with ECL in general) was a good idea on paper but never really progressed beyond the very high end, mostly due to cost as I understand it. I am not aware of anyone besides CDC shipping R6000 machines to the general public, and a post from mid '91 I found on google groups claims that CDC said they only had 48(!) R6000 systems installed at that point. With that astonishingly low real-world volume, I really don't see how the R6000 can be considered anything but a total failure, especially when compared to the R3000 or R4000. 208.66.211.217 05:40, 15 October 2007 (UTC)

XMT

Univeristy of Maryland - College Park has a team working on XMT, an Explicitly Multi Threaded MIPS core. --Rektide 19:35, 1 October 2007 (UTC)

Does the XMT have capabilities beyond the MTI 34K core, which is a commercially available multi-threaded MIPS CPU? Dyl 05:47, 2 October 2007 (UTC)

XMT's current physical incarnation is as 64 simple in order cores specifically built to do data parallel computation, and their simulations target 64 "functional groups" consisting of 64 processors surrounding a shared memory pool. Rektide (talk) 17:29, 5 March 2009 (UTC)

Opcode versus Assembly

The article seems to confuse opcodes and assembly language. I have attempted to fix this to some degree. —Preceding unsigned comment added by 128.163.7.129 (talk) 17:22, 4 October 2007 (UTC)

Higher speed R3000 and R4000 Chips?

The source for Ultrix supports detection of 45, 50, 55 and 60MHz R3000 chips as well as 133 and 150MHz versions of what appear to be straight R4000 chips (labeled as "supported"). Does anyone know if any of these actually shipped? 208.66.211.217 05:03, 15 October 2007 (UTC)

false statement : However, as Intel quickly released faster versions of their Pentium class CPUs, Microsoft Windows NT v4.0 dropped support for anything but Intel

this is untrue, there was a Windows 4.0 release for DEC Alpha too. —Preceding unsigned comment added by 62.212.109.174 (talk) 09:51, 2 November 2007 (UTC)

How can a controller become a MIPS controller?

This article describes some MIPS controllers. But there is missing a definition, what a MIPS controller really is. Is it sufficient, if he has got the assembly instruction set of MIPS? ... or what more? -- 84.132.61.173 (talk) 04:26, 21 November 2007 (UTC)

"Controller" is an old name for the System-on-a-chip -- Alecv (talk) 12:10, 21 November 2007 (UTC)

Thank you for the answer. But sadly this does not answer the question. I know what a "controller" is and work with some of them. The question was, what a MIPS controller is. And the article does not explain that. It only explains, which controllers are MIPS controllers. Imagine, somebody tells you, that this object is a car. But he does not tell you, that a car is used for driving. Thus you do not know, that you have to learn driving to use the object. This article si similar. Supposed I know, that I have got a MIPS MK4 compatible Controller. How does this information help me, to use it? -- 84.132.74.53 (talk) 13:11, 8 March 2008 (UTC)

Description of addu / addiu is wrong (I think)

Sorry if this is the wrong place or format for this - first time I've had reason to question anything here.

The description of add / addu etc looks wrong to me. I believe the difference between add and addu is that the latter does not trap on overflow to bit 31. And I'm not sure, but I think that on a 64-bit processor, these adds are always 32-bit adds, and the result is always sign-extended to 64 bits, even for addu. But I'm less sure about that second bit.

And for addiu, I belive the constant is sign-extended, but then an addu is performed (ie no trap on overflow).

Seems to be missing sltu and sltiu (unsigned comparisons) - again, sltiu takes a signed 16-bit constant, then does an unsigned comparsion. I think.

Also missing sllv, srlv, srav, which shift by an amount in a register, rather than a constant.

And missing some conditional branches for register-zero (bgez, etc) Says bgtz is a pseudo instruction, but my mips book lists it as a real instruction (top 6 bits %000111)

And the conditional traps (TEQ, etc)

--217.45.130.237 (talk) 18:38, 12 December 2007 (UTC)

PIC32

The Microchip PIC32 family seems to be MIPS based. I don't really know much about this family, but it seems like they deserve a mention in here. Does anyone know more? --Mr z (talk) 01:39, 17 January 2008 (UTC)

[2] sez MIPS32 m4k core. --moof (talk) 15:53, 17 January 2008 (UTC)

MIPS based Supercomputers

I added a section on MIPS based supercomputers to showcase the fact that the MIPS architecture has not been relegated to merely relatively low performance embedded applications. I am not an experienced editor however, and don't know how to upload images and create reference links. I humbly request that an experienced editor add links to the relevant SGI and SiCortex documentation and images. Links to the relevant supporting documentation and system pictures are here:

SGI Origin 3000 product info: http://www.sgi.com/products/remarketed/origin3000/

SiCortex Technical Summary http://sicortex.com/var/ezwebin_site/storage/original/application/125e5be6a574a4c0f4dd1ad475344e49.pdf

SC5832 thumbnail: http://regmedia.co.uk/2006/11/19/sicortexbig.jpg Node board thumbnail: http://regmedia.co.uk/2006/11/19/sicorboard.jpg

These images were sent out to the media in an open press release so I assume there is no copyright issue in using them on Wikipedia.

Since the SiCortex system is currently the only MIPS based supercomputer on the market, I think it would be proper to show a thumbnail of the SC5832 chassis. Considering the uniqueness of the system architecture, and the ingenious chip level integration, the 27 chip node board should be included as well. Maybe show both thumbnails, one on top the other with a short caption for each: "SC5832 Supercomputer" for the system chassis thumbnail, and "SiCortex processing board: 27 node chips containing 162 MIP64 cores"

69.155.191.69 (talk) 20:02, 8 April 2008 (UTC) Stan Hoeppner, St. Louis, MO

Unsigned vs. Signed Add/Subtract is a Misnomer

The MIPS ISA supports these six instructions:

• Add (Add)
• Add Unsigned (Addu)
• Add Immediate (Addi)
• Add Immediate Unsigned (Addiu)
• Subtract (Sub)
• Subtract Unsigned (Subu)

There is confusion all over the MIPS implementing world about the meaning of unsigned in these instructions. At least, the current v2.50 of The MIPS32 Instruction Set clearifies that this is a misnomer: The unlabeled (signed) varianst behave the same as the unsigned ones. The only difference is that in unlabeled (signed) commands that result in an overflow, an overflow trap is executed, whereas the unsigned commands silently ignore the overflow. This misnomer is present for decades now, and Wikipedia should stand front row fighting this confusion. This was not introduced in later-than-MIPS-I ISAs, but the clarification might have been added later on.

• There is no point in having registered Add vs. Add Unsigned: There is no difference adding signed vs. unsigned if there is no room for sign extension (the result is computed over all 32 bits anyway)
• The same applies to Sub vs. Sub Unsigned
• As the constant is known at compile/assemble time for Add Immediate vs. Add Immediate Unsigned, there is no reason for sign-extending it. If sign extension of the operand would have been the idea behind separating two commands, it would have been far more practical to call these two operations Add Immediate and Subtract Immediate which was obviously not done. Contrary, always applying sign extension to the immediate operand CONST implicitly allows a Subtract Immediate to be converted into an Add Immediate with negated value, and following the nomenclature of the other four instruction commands, enabling or disabling the trap is far more useful than saving one additional bit of the constant operand.
• Just a final clue: If this was a correction of recent MIPS architectural changes, wouldn’t they have changed the name of these commands to clearify things instead of changing behavior and making a note about the misnomer, leaving alone the question why they should have changed the instruction set in this very fundamental area of arithmetics?

The emm (talk) 16:20, 19 August 2008 (UTC)

Having consulted my MIPS documentation, I think that your edits are justified. I apologize for my hasty reverts. Rilak (talk) 11:24, 20 August 2008 (UTC)

Thanks for the confirmation! The emm (talk) 12:09, 20 August 2008 (UTC)

How about we just agree that the 'u' really stands for 'unchecked' ?? I guess the confusion arose because the check is a signed-arithmetic overflow check, so you need the addu for doing unsigned. Thus it sort of makes sense to call it unsigned, but even that is weak because e.g. C compilers need to ignore overflow in both signed and unsigned ops, so would use addu for all. 216.191.144.135 (talk) 16:25, 27 October 2008 (UTC)

Immediate pointers?

I've just removed a statement to the effect that pointers could be stored in the instructions themselves. I'll admit my MIPS assembler is rather rusty but I'm pretty sure that isn't the case. For a start the immediate values are limited to 16 bits so you could only ever address 64KB in this way. What you do get is 16 bits to specify an offset from a pointer in memory - you can't have a complete pointer in the instruction itself. I suppose that you could access the first 64KB directly in this manner (using $0) but that doesn't strike me as particularly useful since it would still be a fixed location. CrispMuncher (talk) 17:28, 3 March 2009 (UTC).

I'm no MIPS expert either and I didn't wrote the original text, only tried to make it a little more coherent. My take on your statement above somewhat depends on whether you reagard constant jump-destination addresses as pointers or not; definitions vary, some argue (C-programmers mainly) that pointers are variable addresses, per definition, some argue they are synonyms. Myself, I don't care much for rigid and narrow definitions of single common words, even in narrow contexts. HenkeB (talk) 00:44, 4 March 2009 (UTC)

XBurst

XBurst redirects here - it would be extremely helpful if the XBurst CPU would be even named in the article