[Jacques]

I'll try it on my O2 today, if I can sort the license file.

[jan-jaap]

The O2, is a 64-bit machine, so it will run WF2.

Actually, it's not. The processor is capable of 64 bit but the O2 does not run as a 64 bit computer, at least software-wise.

It's been years and my brain is not so good, j-j can explain better but IP 32 does not run 64 bit programs. It may just be that since the O2 can't install more than 1 gig memory, SGI just pulled the useless components out of an O2 install and manual addition of those components would make it work. Don't know, never tried.

IRIX installs a 32bit kernel for the O2 (IP32). I think it's just question of  product placement, because technically any system with an R4000 CPU or newer can run 64bit code, and in fact OpenBSD runs a 64bit kernel on the O2. Also, 64bit kernels and applications come with a performance penalty on IRIX: when pointers are twice as big, you run out of cache twice as fast and it's more demanding on the memory system. This is the opposite of x86_64 vs i386 because in the x64_64 ABI they scrapped a lot of cruft so the result is usually faster.

This is the reason the N32 ABI exists: you get full access to the 64bit goodness of the CPU, but minus the overhead of 64bit pointers. A 64bit data type (long long int) in an N32 applications is a single register, in the O32 ABI it takes two 32bit registers. For most applications, N32 is what you want. Only if you want to manipulate more than 4GB RAM (well the limit is lower, because part of the address space is used by the kernel), does the N64 ABI make sense.

The sort of applications that fill this niche (like WF2), have no business on an entry level workstation like the O2. You's want an Octane for that. Like I said, product placement. There's the oddball Indigo2 R8000 and Indigo2 R10K which run a 64bit kernel, when max RAM was specced at 640MB. Technically that doesn't make sense, but I remember back in the day we used an Indigo R10K to develop for a large PowerChallenge in the data center. If not for the 64bit Indigo2 we'd have to debug everything on the Challenge and that was a pain, and a waste of cycles of the expensive Challenge. This was a time when 64bit code was brand new, and 64bit clean code was a pipe dream, so the Indigo2 was very very useful.

[lunatic]

IRIX installs a 32bit kernel for the O2 (IP32). I think it's just question of  product placement, because technically any system with an R4000 CPU or newer can run 64bit code, and in fact OpenBSD runs a 64bit kernel on the O2. Also, 64bit kernels and applications come with a performance penalty on IRIX: when pointers are twice as big, you run out of cache twice as fast and it's more demanding on the memory system. This is the opposite of x86_64 vs i386 because in the x64_64 ABI they scrapped a lot of cruft so the result is usually faster.

the x86_64 architecture also expanded the whole x86 architecture. You also get twice as many registers. That's why x86_64 is usually faster than x86 code.

This is the reason the N32 ABI exists: you get full access to the 64bit goodness of the CPU, but minus the overhead of 64bit pointers. A 64bit data type (long long int) in an N32 applications is a single register, in the O32 ABI it takes two 32bit registers. For most applications, N32 is what you want. Only if you want to manipulate more than 4GB RAM (well the limit is lower, because part of the address space is used by the kernel), does the N64 ABI make sense.

The sort of applications that fill this niche (like WF2), have no business on an entry level workstation like the O2. You's want an Octane for that. Like I said, product placement. There's the oddball Indigo2 R8000 and Indigo2 R10K which run a 64bit kernel, when max RAM was specced at 640MB. Technically that doesn't make sense, but I remember back in the day we used an Indigo R10K to develop for a large PowerChallenge in the data center. If not for the 64bit Indigo2 we'd have to debug everything on the Challenge and that was a pain, and a waste of cycles of the expensive Challenge. This was a time when 64bit code was brand new, and 64bit clean code was a pipe dream, so the Indigo2 was very very useful.

It can be good to offer a common architecture across a wide range of systems. Sun did that very successfully. What you describe was very common I think.
Even though the R4000 was technically a 64bit CPU, hardly anyone used that and ran a true 64bit kernel with 64bit pointers. The only machine I can remember at the moment is the SGI Challenge/Onyx (IP19 with IRIX >= 6). The smaller SGIs didn't, DEC didn't, Sony didn't, even MIPS didn't.

[Irinikus]

Jan-Jaap, thanks very much for sharing your insight on this subject, I really appreciate it!

I really didn't know that about the O2!

[jan-jaap]

It can be good to offer a common architecture across a wide range of systems. Sun did that very successfully. What you describe was very common I think.
Even though the R4000 was technically a 64bit CPU, hardly anyone used that and ran a true 64bit kernel with 64bit pointers. The only machine I can remember at the moment is the SGI Challenge/Onyx (IP19 with IRIX >= 6). The smaller SGIs didn't, DEC didn't, Sony didn't, even MIPS didn't.

Well, you have to consider the timing, and go back to ~ 1992 for a moment. Back to the days when RISC would take over the world and replace the PC 

10/91: Introduction of the R4000, the first general purpose 64bit RISC CPU if I'm not mistaken. At the time many RISC vendors were racing to get their 64bit products to market.

01/92: Introduction of the Crimson. Crimson was an interesting hack: a new R4000 CPU board for an existing 32bit architecture to reduce time to market. Unfortunately, the PowerPath bus of the PowerSeries  would hold back the R4000 too much, so main memory had to be on the CPU board. No MP R4000 system was possible. Software was IRIX 4.0.x. People start asking for a 64bit OS (for this system, limited to 256MB RAM).

01/93: Introduction of the Challenge / Onyx, MP R4000 systems. Even though these systems supported > 2GB RAM, IRIX 5.0 did not support it. In fact, IRIX 5.0 was a bit of a disaster that nobody used unless you were the sucker who bought an Onyx, the rest was on IRIX 4.0.5. IRIX 5.0 introducted many new things: ELF binaries, what we now call the O32 ABI, large parts of IndigoMagic rewritten in the then-new and not yet standardized C++ language. Many bugs and memory leaks. There's an infamous leaked internal memo that describes it better.

07/93: Introduction of the Indy, running IRIX 5.1. You still had to reboot it weekly due to memory leaks. The IRIX 5 software was using so much memory that a joke doing the rounds said "The Indy was the Indigo without the go".

06/94: Introduction of the R8000 PowerChallenge and IRIX 6.0 (forked from IRIX 5.2). First OS with 64bit kernel, introduction of the 64bit ABI and a new set of compilers which later became MIPSpro. Again, this was something you didn't use unless you had no other option. The compilers were a disaster, mis-compiling valid code, and lacking instrumentation to detect portability errors in exiting code. Life was not good, but only people doing numeric simulation on big iron were suffering.

11/94: IRIX 5.3. After nearly 2 years this plugged most of the bugs in early IRIX 5. This was finally a stable and usable system. So at this moment we have a 32bit platform (IRIX 5.3) capable of running ELF-O32 binaries and a IRIX 6.0/6.1 which ran ELF-64 as well.

03/96: IRIX 6.2. The "all platforms" release: basically every system with an R4000 or better CPU will run it. But unless you had a Challenge with multiple memory boards there still was no need for 64bit pointers. Actually, most Indys shipped with only 32MB RAM. A compromise was made: entry level systems shipped a 32bit kernel, big iron (and the PowerIndigo2) a 64bit kernel. The N32 ABI was introduced which had better been called 64bit-lite or something because really, it's the best of both worlds for 64bit capable systems with < 4GB RAM. By them the MIPSpro compilers more or less worked. Life was good again.

As you can see it took a good 4 years between the introduction of the first 64bit system, and a stable OS that would bring 64bit operations to all supported systems, without wasting performance on 64bit pointers where it didn't make sense. Since IRIX 6.2, you basically have the N32 and 64bit ABIs to choose from, and O32 is legacy. You could argue that O32 should never have existed but hindsight is always 20/20 I guess.

[jpstewart]

Thanks for that detailed history lesson, jan-jaap. It's that sort of stuff that I enjoy most on these forums.

[02girl]

Finally got my Indy out of the closet, moved the baby's clothes to another room. Irix 6.2, it's been a while. Tried to get MicroStation and AutoCad running, with no success. Paths? So here is a screenshot of ivview, and a photo of a real prototype.

[RageX]

I think ProE is your best bet. I think the install files are floating around out there and license generators too. I would try to find v20, it will run better on older hardware. It has some updated toolbars and menu buttons that make it more akin to a modern piece of software, but still has the old menu manager interface which was very efficient. It still uses the same type of license files as the newer software. It's been a long time and I can't remember if a license for a newer version allows for running an older version of the software. If it does you should be good.

Here's a screenshot from v20 running on an Indy XZ for reference: http://siliconimage.irixnet.org/var/albu...1577163311

Someday when I get around to it I would love to get a real vintage version, say v17, running on an Indigo or Indigo2 and all setup just like back in the day... Unfortunatley I think the licensing system for v17 is different. I actually have codes and info from one of my old jobs but it's tied to a non-SGI MAC address. Havne't got into trying to get it to work...