SGI: Development

Just noticed a couple-months-old post on the GCC list bringing up the possibility of obsoleting IRIX before 6.5 (and Solaris 7, Tru64 before 5.1).

Towards the end it looks like they're moving more to possibly obsoleting the o32 ABI or IRIX and maybe 5.3, but I don't know where that leaves 6.2.

Since 6.2 doesn't include a SGI compiler (IRIX 5.3 does), supports POSIX, is Y2k clean, and doesn't have a current (c99) MIPSpro compiler perhaps we should lobby for continued support.

FWIW 6.3 and 6.4 are included in the original idea as well - I know some people run 6.3 on O2, haven't met any 6.4 people myself.

We should be able to scrape up equipment for test builds here - I personally have a Challenge R10k that has a 6.2 system disk option.

sure there's a compiler for 6.2. the 6.2 IDO installs a compiler. what am i missing?

Your memory?

The C compiler was part of the 5.3 IDO, but with 6.2, compilers were marketed as separate products and were no longer included in the IDO.

Also, with 6.2, the IDO was broken into two components, the IDF (foundation) and the IDL (libraries), much like in IRIX 6.5.

As an aside, the 6.2 IDF/IDL can be downloaded from ftp://ftp.sgi.com/sgi/IRIX6.2/

welp, i have three CD's i also loaded on 6.2, IDL, IDF, and IDO. at least that's what i marked on the CD's . i didn't have originals.

so what do you suppose i have here? after i load them i have full functioning compilers. i don't have a machine up and running at the moment to check the contents. oh well... what's in a name anyway, or in this case an abbreviation.

This change is already done, see http://gcc.gnu.org/gcc-4.5/changes.html


I'll take a quote from Rainer Orths mail ( http://gcc.gnu.org/ml/gcc/2010-01/msg00510.html ):

Unless you're going to do that then lobbying for continued support is pointless and disrespectful.

His reasoning for obsoleting is fair and I think it's the right decision.
Rainer has been the only GCC maintainer for IRIX for many years and the community owes him respect for a good job done.

Just be happy that IRIX 6.5 is still supported and that we're stuck with 4.4.x (or even 4.5.x) and not 3.4.6 for IRIX < 6.5.


I've never seen a gcc testresult posted for IRIX 6.3 or 6.4.
It's a non-issue.


Donating cycles to making the very best gcc 4.4.x (or 4.5.x) release possible for IRIX < 6.5 would be nice.
But someone still needs to be around to actually fix the bugs.

-tgc

As you've pointed out in the past, there's quite a lot in a name, or an abbreviation, particularly in a technical field. I guess that's one reason why marketers and engineers generally have such positive views of each other.

I think we both agree that precision in language is extremely important...and I think it helps us to get to the bottom of things here.

First off, you are correct, and I was (partly) wrong.

Some of the issue is version specific, some of it is due to ambiguity in SGI documentation, and some of it is due to folklore.

In short, the official IDO product did, indeed, include the C compiler into the 6.4 era, so skywriter is correct.

However, by MIPSpro 7.2 (basically the 6.5 era), SGI documentation said things like "the IRIS(R) Developer's Option (IDO) CD was replaced by the IDF and IRIX(R) Development Libraries (IDL) CD sets." Likewise, other bits of the IDO were broken out into separate products. For example, DBX, SpeedShop, ProDev WorkShop, and WorkShopMPF all became part of a new "ProDev Workshop" product release.

Before IRIX 6.5, SGI made the IRIX 5.3 IDO available for free download, and it also made the 6.2 IDF and IDL images available for download in a similar place. I'm pretty sure that this is where the erroneous conflation of IDO = IDF + IDL got started, and, as above, SGI documentation does little to dispel the notion.

The situation was confusing enough that it got its own entry in the hallowed SGI FAQ - http://www.faqs.org/faqs/sgi/faq/apps/section-5.html

For my own part, I only state lamely that, starting in the IRIX 5.3 era, I worked in an environment that did C, C++, and Fortran programming, so I always ordered compilers as individual products, not really thinking about the IDO per se .

I'll save the memory jokes for myself, and I yield the field to skywriter (though I will italicize per se , lest my extremely traditionalist 8th grade English teacher, Mrs. Hughes, rise from the grave to exact her vengeance upon linguistic revolutionaries).

In addition to all the compelling reasons given by tgc, I notice that support for Solaris 7 is being dropped, too. I think it's very hard to argue against dropping pre-IRIX 6.5 support when a gigantic release like Solaris 7 is also being consigned to the dustbin of gcc history.

thanks joe! it was pretty confusing looking at the pile of cd's i had for 6.2. sadly i have no remaining use for them.

I brought up 6.2 specifically because his reasons for dropping seem to be primarily concerned with equipment to test on (same case with Solaris 7). If that's the concern then it's not a big deal for me to run builds on the Challenge (for that matter I could put Solaris 7 on an Ultra 2 if that would be helpful). The technical difficulty seems to resolve around o32, and since IRIX 5 has other issues with modern standards compliance (no POSIX libpthreads among others) it's unlikely that programs requiring newer compilers would build anyway.

I was aware of IDO 6.2 and successor versions, but it was never made available as a free download from SGI, rather it was always an extra-cost option. For IRIX 5.3 cc was included in the downloadable IDO5.3, so GCC isn't as big of an issue (it would be for C++ support, but again it's unlikely that a program requiring a modern C++ compiler would even build on IRIX 5.3).

I've been doing this for while, but you must not underestimate building GCC. First of all you need a dozen or so support packages in place, and a fairly complete set of GNU tools. A full bootstrap build + regression test takes the best part of a day on my Origin 300. Older IRIX means older hardware means longer build times.

Rainer Orth, who has put by far the most effort into GCC on IRIX says building an IRIX 5.3 GCC takes nearly a week for him. I cheat a bit and can do it in an IRIX 5.3 sandbox on my Origin 300 (yes: IP35-irix5.3 ) in around 7 hours I think. You cannot sandbox IRIX 6.2 inside 6.5 because nothing depending on pthreads will work.

You cannot expect "GNU" to support systems indefinitely, having been EOLed by their manufacturer for 10+ years.

So I've got the O300 in the rack at work and it does automatic regression builds. It need a bit of hand-holding to keep up with dependencies and the occasional breakage. But that's not the problem. You need to analyze what comes out -- compare results, find the source of breakage, provide patches, and be responsive on the mailing lists. In reality, I don't have the time for this. I've got a busy job, wife, baby boy etc. etc. Instead I maintain a private patch set which fixes the worst breakage and build compilers when I have the time, not on a schedule or when upstream decides it's the time.

I've got a new 12x R10k Challenge L which is almost ready to roar. I can do the occasional GCC builds on that too, and I plan to help Tom with TGCware, but again, it's not realistic that I'm going to keep up with GCC SVN HEAD.


This is exactly what is feasible in the limited time I have available.

I don't think anyone does

The older versions of gcc still work on the old hardware so I don't see a problem, myself. New software isn't going to run well on Personal Iris anyhow.

The newer GCC probably doesn't even run well on the older Personal IRISes.

I'm not sure how MIPS optimization is going currently, but I remember that for a while (GCC 3.2-3.3 era) they were making substantial improvements on the MIPS compilers. If that's still going on (substantial speed/generated code improvements) then it would be beneficial. If not I suppose it isn't that big of a deal. GCC 4.x does c99 and all that jazz.

GCC 4.x currently doesn't run at all on any machine with an R3000 CPU, and neither does any code built with it.
I have the feeling some mips2 instructions have sneaked into the crt code.

Both GCC 3.x and 4.x can consume more memory than you can install on many of the early systems, especially when compiling larger C++ files.