SGI Announces MIPS and IRIX End of Production 275
ramakant writes "Considering the recent news regarding their dismal financial situation, it should come as no surprise that SGI announced end of production for MIPS based hardware and the IRIX operating system. From the article: "SGI launched the MIPS/IRIX family of products in 1988. Since then, this technology has powered servers, workstations, and visualization systems used extensively in Manufacturing, Media, Science, Government/Defense, and Energy. After nearly two decades of leading the world in innovation and versatility, the MIPS IRIX products will end their general availability on December 29, 2006." IRIX has always been my favored OS, and I'll be sad to see it gone. Hopefully my O2 will survive for many years to come."
Too bad - MIPS was pretty (Score:5, Interesting)
Alpha, MIPS, and others - where are you now? x86-2^x is pretty much all that's left for general-purpose programming these days (although Sun might have something to say about that), and that's too bad. Kind of like how you can't be a great programmer without ever having seen Lisp, you can't be a great chip designer without ever having known something that doesn't run IA32 code.
FOSS (Score:5, Interesting)
Re:SPARC? (Score:2, Interesting)
I do know that PSU *used* to teach SPARC in a standalone assembly course, but that was later combined with the org class and at that point changed to MIPS.
(BTW, an addendum to my original post, I know that there are plenty of SGI machines around, so "narrowly-deployed" is probably too harsh. That said, the only time I've run any MIPS code we wrote in that class was on SPIM.)
Make patches available (Score:2, Interesting)
It'd be nice though.
Re:MIPS is going away? (Score:3, Interesting)
Re:Pick an OS with staying power (Score:5, Interesting)
This is UNIX! You're supposed to be able to take your ecology with you to Linux, or Solaris, or OpenBSD, or wherever. With some pain, admittedly---but little more pain than if you're migrating from, say, RedHat to Debian.
Re:SPARC? (Score:4, Interesting)
Hopfully we can convince the CS dept to move their course off of MIPS so we can push these aging servers off the end of the loading dock. SPARC or x86/64 would be the alternatives here.
Re:Such a crowded graveyard, big deal. (Score:4, Interesting)
When left to their own devices most of the large computer companies (IBM, HP, Dell, even Intel, AMD, Cisco etc etc) do very little revolutionary or insightful things. They usually tread water with minor "improvements" until someone comes along and kicks them in the pants (see: IBM vs Apple, IBM vs DEC, Intel vs AMD etc etc) with some better technology.
If all we have left are the "big guys" where is the next revolution going to come from ?
Re:FOSS (Score:5, Interesting)
Re:IRIX was obviously going away. (Score:3, Interesting)
MIPS died years ago. Long live, ARM! (Score:1, Interesting)
In fact, senior managers at Intel personally flew to Taiwan to "encourage" board makers to stay with Intel despite the significantly higher performance of MIPS. At the time, the MIPS R2000 was significantly faster than the Intel 80386. Intel management understood the problem and eventually whipped its slaves into producing the 80486.
So long, MIPS. Good riddance.
Hello, ARM! The ARM instruction set is open for anyone to implement. The patents that ARM holds apply only to the implementation but not to the instruction set itself. If you can figure out a way to implement the instructions in a way that differs from ARM's patented implementation, then you are free to do so.
ARM is quite unique. Both MIPS and SPARC resulted indirectly from millions of dollars of government funding at Stanford University and UC-Berkeley. By contrast, ARM was developed on a shoestring budget: its aim was to develop a successor to the 6502. We (yeah, that means you) loved the 6502 for its simplicity. ARM inherited that simplicity.
Further, the simplicity means incredibly low power consumption. If IBM had committed to ARM instead of building the PowerPC, ARM would eventually have shared the marketplace with the x86 in both the server market and the desktop market.
As Intel management has discovered, low power is the key. The traditional thinking has been that servers should suffer any amount of power usage for a higher clock frequency. However, once clock frequency is so high (i.e., exceeding 1 gigahertz) that power usage exceeds 100 watts, the power causes two serious problems: (1) high electricity bills and (2) degradation of server reliability (due to damage caused by heat to the other components in the system)
Of course, ARM has a built-in advantage due to its simplicity. Unfortunately, IBM engineers had a huge ego trip and demanded to build yet another RISC processor -- the PowerPC.
However, there is still time for ARM to succeed in the market for desktops and servers. NEC could commit to building ARM computers and pay Microsoft to port Windows Vista to ARM. NEC has the engineering might to compete against both IBM and Intel. With ARM, NEC has a winner!
No problem: COMPAT_IRIX in NetBSD/sgimips (Score:4, Interesting)
Re:MIPS is going away? (Score:3, Interesting)
PowerPC is superscalar. ARM isn't. (Score:3, Interesting)
If you can figure out a way to implement LZW or RSA or MP3 or any other patented codec in a way that differs from the patent owner's patented implementation, then you are free to do so. Unfortunately, no other way exists because the claims on those methods are rawther broad.
PowerPC was also built to scale to multiple functional units per thread, such that they can run a load, an integer arithmetic, a floating point arithmetic, and a branch at once. Are any ARM implementations superscalar? XScale [wikipedia.org] sure isn't. Or are you talking about a massively multicore CPU, some sort of squared octopus with 64 ARMs?
Re:SPARC? (Score:3, Interesting)
Re:SPARC? (Score:3, Interesting)
I learned x86 asm around 1994 mainly because there was nothing else for a 15 yr old with a PC, and because x86 even back then was pervasive enough.
I was trying to build a boot code virus using instructions and code taken from a BBS server.
I failed to infect my own computer.
Re:SPARC? (Score:3, Interesting)
By contrast, MIPS is too easy. After that, everything else will be harder :)
My first assembly language was VAX. For those who are unfamiliar with it, the great thing about VAX assembler was that there was an instruction for everything. For example there was a machine instruction that performed a quicksort. The old joke was that you could write any program with a single instruction, if you could find it and figure out how to use it.
Re:SPARC? (Score:3, Interesting)
Programming after all is a matter of mastering idioms. Good programming is often largely a matter of choosing sensible conventions and sticking with them. The thing that kills you in the system is lack of orthagonality. Broadly speaking, what I mean by this is that it's important that when you write a program that looks like it ought to be syntactically valid, it should be. Furthermore, it should work more or less the way a sensible programmer unfamiliar with the language would guess it's supposed to work. I'd rather write programs in VAX assembler than Microsoft Transact-SQL dialect because of orthagonality. T-SQL is the most non-orthagonal language in widespread use; you're constantly having to look in the documentation to see if such and so will work in this context.
Re:MIPS is going away? (Score:3, Interesting)
Re:MIPS is going away? (Score:3, Interesting)
1 register you can use that isnt used by something
else ( ax ) ( bx was used for something, cx
was used in some "counting" instructions,
dx would have the most significant 16 bits
of a multiplication ( ax would have the lower,
now that I think of it.... dx:ax would be
the full 32 bit result ). So, ax that, 0 registers
you can use that arent used by something else.
Addressing ( "long" ). 20 bit addressing bus,
16 bit system. So, you load a register with
a 16 bit value, and wink wink, it gets shifted 4 places
left. 20 bits it is now. Then, load another
register with another 16 bit value, which is added
to the other you just did, viola, a 20 bit address.
Dont ask me how the two registers you just loaded
related to each other, I am trying to repress that.