Emulation

I have SGI systems but interested in cloneing a disk to run inside an emulated environment (on Linux x86) . Has anyone emulated irix-mips, sunos-sparc, hpux-parisc or aix-rs6000 on a linux_x86 system sucessfully. I searched the forums for older threads but did not see a solution in relation to the irix side of things.

No one has done it, at least for IRIX.

I am led to believe there is a DEC Alpha emulator that will run either DIGITAL UNIX or Tru64. There is also a PowerPC emulator that can run darwin. Oh, and I've also run UNIX release 7 on a PDP 11 emulator.

There are various emulators for UNIX/RISC platforms available.

PersonalAlpha at the following site can apparently do Tru64, but I haven't tried it out. AFAIK it is from a DEC research project, so it should be fairly good.
http://www.emulatorsinternational.com/e ... lalpha.htm

BTW, you can also run DEC Ultrix using gxemul.

SimOS/MIPS can run a modified version of IRIX 5.3 on an IRIX/MIPS host, but is really slow when using Mipsy CPU model (embra just crashes, but I didn't look into it). SimOS/MIPS also runs on X86, but I couldnt try IRIX in it because the version I use in Linux/X86 has some custom hacks for some MIPS code I was testing. In theory it should work, but there might be some bugs to fix in SimOS first.

For SunOS/Solaris, there were some versions of SimICS that could emulate a SPARCstation. It might be only for SPARC hosts though.

I don't think there is an emulator for HPPA/HP-UX. HPPA isn't a nice architecture, and some of the more unusual features of it would be very slow to emulate.

Also, on the non-x86 front:
SimOS/PPC can do some modified versions of AIX, but requires a PPC host.
SimOS/Alpha can run a modified version of Digital Unix 4, but needs an Alpha host.

kramlq wrote: HPPA isn't a nice architecture ...

Really ? In what way ?

hamei wrote:

kramlq wrote: HPPA isn't a nice architecture ...

Really ? In what way ?

I was kind of speaking generally there, rather than purely from an emulation perspective. Stuff like:
- its rather limited atomic primitives (it can only load and clear a word atomically)
- Disabling virtual addressing and entering physical addressing mode during an interrupt or exception.
- It uses the cache for both virtual and physical modes, which means aliasing issues can occur between the same location accessed via a virtual and physical address.
- Ambiguously defined instructions like cache line operations, which have implementation specific behaviour.
- It has more trap situations than most processors, which means more conditions to check for in an emulator (e.g. trap every time a branch instruction is taken).
- General register shadowing when an interrupt or exception occurs, and live mirroring of certain control registers. That means more overhead for an emulator.

HPPA is certainly not the worst CPU (that would be the IA32 and IA64), but as RISCs go, it isn't the nicest either IMHO.

I thought PA-RISC had its cache virtually addressed, isn't that the case? (at least 1.1 and 2.0 were).

PA-RISC is weird as an architecture for sure though...

R-ten-K wrote: PA-RISC is weird as an architecture for sure though...

From a C programmer's perspective, the oddest thing is that in 32bit mode the stack grows upwards, in 64bit mode the stack grows downwards.

R-ten-K wrote: I thought PA-RISC had its cache virtually addressed, isn't that the case? (at least 1.1 and 2.0 were).

With virtual addressing on, it virtually indexes the cache. In physical mode, it is physically indexed (as thats all it has available). As I said earlier, the CPU enters physical mode for every interrupt or exception, and until the handler turns on virtual mode, any addresses accessed must be "eqivalently mapped" (PA-RISC terminology) in virtual and physical mode, or else what you write in physical mode may not be seen later in virtual mode etc. It has other strange effects as well - for example, the handler itself should be equivalently mapped, or else strange things will happen for the instruction after the one where it switches to from physical to virtual mode.

To go back to the original point.... does anyone feel like writing an emulator that does all this? That is why there are are no emulators.

porter wrote: From a C programmer's perspective, the oddest thing is that in 32bit mode the stack grows upwards, in 64bit mode the stack grows downwards.

Ah yes! How did I forget its most notably weird feature!

Some poor souls at QEMU are trying to get HP-PA emulation going.

Also, didn't the Itanium offer some level of support to emulate HP-PA? Which may be a reason why IA64 is so @#$@#$ up? Trying to offer support for x86 and HP-PA must have been a nightmare, ugh....

Also to be fair to HP-PA, some architectures do require physical addressing for certain privileged instructions. Looking at their docs they are physically tagging the cache, so "equivalent" mapping shouldn't be too bad (probably in some XX megabyte offset chunks). Alas multiprocessing must be a PITA, unless they have some very very clever cache controller going on there.

Anyhow, for those interested in full system emulation. I recommend to take a look at QEMU, full opensource... and they support X86, SPARC, MIPS, PPC, and ARM among others. You may be able to extend it to do your own system emulation if you are so inclined. SIMH does support a ton of old (historical) architectures.

Nai wrote: Has anyone emulated irix-mips

The PlayStation One emulators do R3000 well.

R-ten-K wrote: Also, didn't the Itanium support offer some level of support to emulate HP-PA? Which may be a reason why IA64 is so @#$@#$ up? Trying to offer support for x86 and HP-PA must have been a nightmare, ugh....

A lot of HP-PA features were included into Itanium. The memory scheme, protection scheme, interrupts and even the type of control registers present are somewhat similar. I think it also supports the gateway page mechanism for system calls (which was unique to PA-RISC)

R-ten-K wrote: Also to be fair to HP-PA, some architectures do require physical addressing for certain privileged instructions. Looking at their docs they are physically tagging the cache, so "equivalent" mapping shouldn't be too bad (probably in some XX megabyte offset chunks). Alas multiprocessing must be a PITA, unless they have some very very clever cache controller going on there.

Equivalent mappings are done just like the normal way you would handle virtual aliases. But there are other implementation details that make this "design feature" a pain. Mainly to do with the fact that it affects exception/interrupt handling. If the active kernel stack is not equivalently mapped, you can't even touch that until VM is enabled, so you have nowhere to save the registers. After enabling VM, any faults might overwrite those registers. Lots of issues like that that complicate things for no good reason.

porter wrote: The PlayStation One emulators do R3000 well.

Yeah, MIPS is the easy part, but nothing emulates SGI platform hardware enough to boot an unmodified IRIX kernel. SimOS defines its own hardware, and IRIX had to be ported to that. The Mess (or Mame?) emulator boots to PROM, but AFAIK is incomplete, so can't boot IRIX.

porter wrote:

Nai wrote: Has anyone emulated irix-mips

The PlayStation One emulators do R3000 well.

I seem to remember SimOS at Stanford did MIPS pretty well and had enough SGI HW emulation in to to be able to boot old versions of Irix (I think it was used in the Splash project, what eventually led to cc-numa so Stanford got a lot of info on SGI HW internals, the early prototypes of splash were in fact a bunch of 4D machines glued together).

I was told that the simos people eventually founded vmware based on the technology.

Don't know if it is active (I doubt it).

For mips emulation, here is a repository I have found helpful.

http://www.linux-mips.org/wiki/Emulators

LOL we submitted at the same time about SimOS.

From what I read from you about HP-PA it sounds like the architecture is fairly ugly... it would be interesting to find out why the #$#@ they decided to make those privileged ops such a PITA to deal with. The overhead, in instructions, that introduces in those handlers must have offset the simpler HW (I assume that was their goal). The OS people must have shitted some bricks, but then again maybe that is the reason why HP-UX was so "unique." HP sure did have some odd "isms."

kramlq wrote: For SunOS/Solaris, there were some versions of SimICS that could emulate a SPARCstation. It might be only for SPARC hosts though.

Simics is now a commercial product, and supports a whole raft of targets. SPARC is probably the best represented, with emulated SunFire 3800-6800 (US3/4) with multiple processors, and also the Blade 1500. I also seem to remember an emulated target for the T1/Niagra, but don't see the docs around now. Also supported is an EV5 AlphaPC, ARM5, Itanium, various PPC flavors, MIPS Malta, and x86. Although the x86 will run Windows, and the Suns will run Solaris, the other targets only support Linux, and are mostly useful for embedded development. There are some cool features that I haven't seen in any other simulators--in particular, a simulated Voodoo3 that even does accelerated 3D (using OpenGL on the host machine). However, it is meant to be cycle-accurate, so speed is not a priority.
Anyway, it costs mucho $$, but licenses are free for students . I have a license, but haven't played with Simics as much as I would like.

Wow. I did not know they had commercialized simics. I knew one of the students involved when it was an academic project (still is?) back in Norway (or Sweden?). As the previous poster said under most configs, simics used to be slower than molasses. I assume it still is, because the folks at CMU are currently trying to speed up simics (and possibly other full system emulators) by offloading some of the processor emulation and timing models to their version of the ramp HW accelerator (a board with a bunch of FPGAs interconnected). They used to have some public systems running a frontend executing simics, and 16 SPARCS accelerated via FPGAs. It was quite interactive, pretty neat since it is a large multicore system fully emulated (normally you would be lucky to get thousands of instructions emulated per second in an architectural simulation of so many cores, basically a 2 second benchmark would take a day to run).

If you are interested, you can get QEMU to model a full sparcstation (maybe they have included ultras by now) and can boot solaris off it.

R-ten-K wrote: LOL we submitted at the same time about SimOS.

From what I read from you about HP-PA it sounds like the architecture is fairly ugly... it would be interesting to find out why the #$#@ they decided to make those privileged ops such a PITA to deal with. The overhead, in instructions, that introduces in those handlers must have offset the simpler HW (I assume that was their goal). The OS people must have shitted some bricks, but then again maybe that is the reason why HP-UX was so "unique." HP sure did have some odd "isms."

I should be fair and balanced like Fox News. It did include a load of things like shadow and scratch registers etc. to give some room to work in - more so than any other architecture until Itanium, but IMHO, the overall design was still pointlessly complicated. Maybe we will see a tell-all "Confessions of a CPU Architect" book some day where they will explain the real reasons why they do these things (they were hungover the day they designed that feature... etc).

Simics is now a commercial product, and supports a whole raft of targets. SPARC is probably the best represented, with emulated SunFire 3800-6800 (US3/4) with multiple processors, and also the Blade 1500. I also seem to remember an emulated target for the T1/Niagra, but don't see the docs around now. Also supported is an EV5 AlphaPC, ARM5, Itanium, various PPC flavors, MIPS Malta, and x86. Although the x86 will run Windows, and the Suns will run Solaris, the other targets only support Linux, and are mostly useful for embedded development.

Yeah, I knew about the commercialised version from Virtutech (and also the cost!) but didn't know they had free student licenses, so I didn't mention it. Though Solaris/SPARC is essentially the same code as Solaris/Intel, so it is as easy to just run it natively, or in an X86 emulator/virtual machine.

If you can access some back issues (as in 80s vintage) of IEEE Computer magazines, you will read some very candid articles which include the design decisions/trade offs behind some of the major architectures. Attending some of the panels at ISCA/MICRO/ASPLOS, ISSCC, or hotchips is always a hoot when interacting with industry people.

From what I have read, It seems that the HP-PA was truly made by committee: it was based on a previous CISC effort, had to support their legacy minis, and someone decided to bolt on the latest "RISC" fad to make it buzzword compliant. But it always seemed like an odd RISC. I think the feature I remember was their odd cache strategy: usually they implemented a single very large cache level. Which from what I was told, was probably because they had some serious issues with register spills. And now that you brought the handler issues, it makes a lot of sense to have a big honking cache when so much overhead is expected when servicing interrupts, exceptions, etc.

I also remember that at some point, the next generation Amigas were supposed to be based around HP-PA? It must have been weird to be motorola in the 80s, everyone leaving you for yet another RISC vendor.

kramlq wrote: I should be fair and balanced like Fox News.

Ah, the Liberal media !

Thanks, kramlq, laughed out loud at that one

hamei wrote:

kramlq wrote: I should be fair and balanced like Fox News.

Ah, the Liberal media !

Thanks, kramlq, laughed out loud at that one

While we've got you two dissecting the shortcomings in processors, how about the Power lineup ? And where does the Itanic really fit in ? Would it have been the processor to end all processors if it hadn't been such a bust ?