7 ms·

As an amusing side-effect, the team working on this effort also implemented IRIX userland support for QEMU since the original N64 toolchain ran on IRIX on the S

by bri3d 7y ago

As an amusing side-effect, the team working on this effort also implemented IRIX userland support for QEMU since the original N64 toolchain ran on IRIX on the SGI Indy, and they need the original compilers to verify functional equivalence of their source: https://github.com/n64decomp/qemu-irix https://github.com/n64decomp/qemu-irix .

WalterGR 7y ago
the team working on this effort also implemented IRIX userland support for QEMU What does this mean? I think of QEMU as emulating hardware... What exactly is being emulated here?
- tw04 7y ago
  It means they managed to get irix running in qemu. Presumably on an x86 cpu. Notable because the sgi indigo had a MIPS R3000A CPU. https://en.m.wikipedia.org/wiki/SGI_Indigo https://en.m.wikipedia.org/wiki/SGI_Indigo
  - Frenchgeek 7y ago
    There is some alpha generic mips support for qemu ( https://www.linux-mips.org/wiki/QEMU https://www.linux-mips.org/wiki/QEMU ), so it could be a set of patches to run IRIX on Qemu's generic MIPS machine emulator...
  - messe 7y ago
    > It means they managed to get irix running in qemu. Presumably on an x86 cpu. Not quite. It means that they got qemu to emulate IRIX's syscall layer on linux. So you can run, lets say, a MIPS IRIX binary on x86 linux without having to emulate the entire machine.
  - bri3d 7y ago
    No - qemu supports "userland" emulation where the processor ISA is emulated but syscalls and memory are translated to the host OS. The IRIX kernel and OS doesn't run in this scenario.
    - barbs 7y ago
      From my limited understanding stemming from a passing interest of such things: that sounds similar to how WINE operates, is it not?
      - ObscureScience 7y ago
        WINE is not emulating/translating instructions to a diffrent ISA. It rather has a win32 loader and inserts some shims to map some calls to windows library functions and others to native(as in host ex. Linux). That's how I understand it. You can however theoretically run x86 WINE to run a x86 windows binary on ARM with Qemu user emulation.
        DaiPlusPlus 7y ago
        Doesn’t WINE support 16-bit emulation for Win311-stuff because you can’t run 16-bit code in x64 mode? Or was that a Windows limitation?
        monocasa 7y ago
        That's a Windows limitation. X64 chips are plenty capable of running 16-bit protected mode code while the OS runs in long mode. It's that Windows didn't want to deal with translating HANDLEs back and forth between the two modes.
        jsjohnst 7y ago
        Not to my knowledge, I believe WINE targets Windows 95 and newer. There is no ISA emulation, just DLL and other related Windows emulation.
        chungy 7y ago
        Wine has never ran 16-bit Windows programs in 16-bit mode. They are instead translated to 32-bit at runtime using some magic, especially using 32-bit addresses to emulate 16-bit real mode.
      - nwallin 7y ago
- bri3d 7y ago
  QEMU is thought of as a hardware emulator, but supports "userland" emulation where the processor ISA is emulated but syscalls and memory are translated to the host OS.
  - yellowapple 7y ago
    I didn't even know QEMU could do that. That's insanely cool; kind of a weird combination of traditional virtualization and Wine.
    - kanox 7y ago
      On a distro like debian you can even use it to build-and-run userspace binaries for an unrelated architecture (some chroot magic was required last time I checked).
      - LukeShu 7y ago
        You (1) use binfmt_misc to tell the kernel to use `qemu-ARCHITECTURE` to run binaries for that architecture, then (2) make sure you also have all of the libraries that the binary is linked against, then that binary executable should just run seamlessly. Now, if your ARM binary was compiled to look for libc at /lib/libc.so, but /lib/libc.so is the host's x86 libc, then that obviously won't work; and the easiest way to get the libraries all sorted out is to use a chroot with OS install of the target architecture. If you do go the chroot route, you need to make sure that `qemu-ARCHITECTURE` is statically linked, because it won't have access to the x86 libraries it needs to run after the chroot(2) call happens (which is why most normally-dynamically-linked distros have a "qemu-user-static" package in addition to their normal "qemu-user" package). But with a multilib scheme like Debian's, where all libraries get installed to /lib/ARCHITECTURE-TRIPLET/ instead of /lib/, then it should be possible to install all of the appropriate target libraries on the host system without a chroot! You "should" just need to configure APT to let you install packages built for that architecture. (I haven't actually tried this; I'm not a Debian user, but I am envious of their multilib).
        7y ago
apacheCamel 7y ago
I honestly love coming to HN to see posts like this and comments like yours. It is always so neat to see the other sides of software engineering. You listed 4 acronyms and I have no idea what any of them are or how they fit into this story but all I want to do is deep dive into each one. It is also awesome to see people so interested in things that I've never even encountered before.
- zik 7y ago
  IRIX [1] was the version of SVR4 UNIX which ran on SGI [2] computers. QEMU [3] is an emulator used to run programs for one machine on another. N64 [4] is the Nintendo 64 games console. SGI Indy [5] was a desktop SGI workstation from 1993. [1] https://en.wikipedia.org/wiki/IRIX https://en.wikipedia.org/wiki/IRIX [2] https://en.wikipedia.org/wiki/Silicon_Graphics https://en.wikipedia.org/wiki/Silicon_Graphics [3] https://www.qemu.org/ https://www.qemu.org/ [4] https://en.wikipedia.org/wiki/Nintendo_64 https://en.wikipedia.org/wiki/Nintendo_64 [5] https://en.wikipedia.org/wiki/SGI_Indy https://en.wikipedia.org/wiki/SGI_Indy
  - ehsankia 7y ago
    I love how you use 3 acronyms to describe the first acronym. It's acronyms all the way down!
    - lstamour 7y ago
      SVR4: UNIX System V Release 4 https://en.m.wikipedia.org/wiki/UNIX_System_V https://en.m.wikipedia.org/wiki/UNIX_System_V UNIX: Actually Unix. Not an acronym. https://en.m.wikipedia.org/wiki/Unix https://en.m.wikipedia.org/wiki/Unix
      - tyingq 7y ago
        "Unix. Not an acronym." Sorta. "In 1970, the group coined the name Unics for Uniplexed Information and Computing Service (pronounced "eunuchs"), as a pun on Multics, which stood for Multiplexed Information and Computer Services."
pg_is_a_butt 7y ago
My professional career started working on University owned SGI Indys. I keep that on my resume. Those machines were my favorite. The token ring coax network was prone to disconnects, and the window manager sucked, but they could solve complex math problems way faster than any other machine I had access to. The math department shared them with the Radiology department to process MRIs.
gdubs 7y ago
I wrote to SGI in high school asking for some info on their computers and they sent back a stack of beautifully printed, full-color brochures. The Indy had a webcam, which was very rare in those days. Also included was a brochure on the Indigo workstation, which Industrial Light and Magic used for Jurassic Park, etc. Nintendo is a little mysterious when it comes to what their actual tooling was, but I remember Donkey Kong Country being the first time I read they were using SGIs (or at least the studio "Rare" was). It's somewhat surprising they used the Indy for developing Mario 64 – I always got the sense that it was somewhat lightweight in performance compared to the Indigo, but a very cool machine either way.
- mrpippy 7y ago
  Those brochures are probably worth real money on eBay if you still have them, a PowerSeries brochure just sold for $200! By the time the Indy came out, the Indigo2 had replaced the Indigo, and I suspect a midrange Indy was a good match for a midrange Indigo1 (at much lower cost). Nintendo made an N64 dev board for the Indy, essentially an N64 on a GIO board, complete with an adapter card to connect controllers.
  - goatinaboat 7y ago
    Indy was a good match for a midrange Indigo1 The joke always was that the Indy was the Indigo without the go :-) But it was a decent enough machine to develop on, you didn’t need the 3D stuff if you spent all day in Emacs or compiling. Whereas an Indigo was really targeted at say CAD users.
    - mrpippy 7y ago
      Haha that was because the base Indy was shipping with 16MB of RAM and IRIX 5 was too bloated for that to be usable. Meanwhile everyone with Indigos kept running IRIX 4 until things got better around 5.3. The Indy had XZ graphics available, which I believe were the same as the top Elan option available on the Indigo (4 GEs)
- segmondy 7y ago
voltagex_ 7y ago
I wonder if it'll ever be upstreamed.

by bri3d 7y ago

WalterGR 7y ago

the team working on this effort also implemented IRIX userland support for QEMU What does this mean? I think of QEMU as emulating hardware... What exactly is being emulated here?

tw04 7y ago
It means they managed to get irix running in qemu. Presumably on an x86 cpu. Notable because the sgi indigo had a MIPS R3000A CPU. https://en.m.wikipedia.org/wiki/SGI_Indigo https://en.m.wikipedia.org/wiki/SGI_Indigo
- Frenchgeek 7y ago
  There is some alpha generic mips support for qemu ( https://www.linux-mips.org/wiki/QEMU https://www.linux-mips.org/wiki/QEMU ), so it could be a set of patches to run IRIX on Qemu's generic MIPS machine emulator...
- messe 7y ago
  > It means they managed to get irix running in qemu. Presumably on an x86 cpu. Not quite. It means that they got qemu to emulate IRIX's syscall layer on linux. So you can run, lets say, a MIPS IRIX binary on x86 linux without having to emulate the entire machine.
- bri3d 7y ago
  No - qemu supports "userland" emulation where the processor ISA is emulated but syscalls and memory are translated to the host OS. The IRIX kernel and OS doesn't run in this scenario.
  - barbs 7y ago
    From my limited understanding stemming from a passing interest of such things: that sounds similar to how WINE operates, is it not?
    - ObscureScience 7y ago
      WINE is not emulating/translating instructions to a diffrent ISA. It rather has a win32 loader and inserts some shims to map some calls to windows library functions and others to native(as in host ex. Linux). That's how I understand it. You can however theoretically run x86 WINE to run a x86 windows binary on ARM with Qemu user emulation.
      - DaiPlusPlus 7y ago
        Doesn’t WINE support 16-bit emulation for Win311-stuff because you can’t run 16-bit code in x64 mode? Or was that a Windows limitation?
        monocasa 7y ago
        That's a Windows limitation. X64 chips are plenty capable of running 16-bit protected mode code while the OS runs in long mode. It's that Windows didn't want to deal with translating HANDLEs back and forth between the two modes.
        jsjohnst 7y ago
        Not to my knowledge, I believe WINE targets Windows 95 and newer. There is no ISA emulation, just DLL and other related Windows emulation.
        chungy 7y ago
        Wine has never ran 16-bit Windows programs in 16-bit mode. They are instead translated to 32-bit at runtime using some magic, especially using 32-bit addresses to emulate 16-bit real mode.
    - nwallin 7y ago
bri3d 7y ago
QEMU is thought of as a hardware emulator, but supports "userland" emulation where the processor ISA is emulated but syscalls and memory are translated to the host OS.
- yellowapple 7y ago
  I didn't even know QEMU could do that. That's insanely cool; kind of a weird combination of traditional virtualization and Wine.
  - kanox 7y ago
    On a distro like debian you can even use it to build-and-run userspace binaries for an unrelated architecture (some chroot magic was required last time I checked).
    - LukeShu 7y ago
      You (1) use binfmt_misc to tell the kernel to use `qemu-ARCHITECTURE` to run binaries for that architecture, then (2) make sure you also have all of the libraries that the binary is linked against, then that binary executable should just run seamlessly. Now, if your ARM binary was compiled to look for libc at /lib/libc.so, but /lib/libc.so is the host's x86 libc, then that obviously won't work; and the easiest way to get the libraries all sorted out is to use a chroot with OS install of the target architecture. If you do go the chroot route, you need to make sure that `qemu-ARCHITECTURE` is statically linked, because it won't have access to the x86 libraries it needs to run after the chroot(2) call happens (which is why most normally-dynamically-linked distros have a "qemu-user-static" package in addition to their normal "qemu-user" package). But with a multilib scheme like Debian's, where all libraries get installed to /lib/ARCHITECTURE-TRIPLET/ instead of /lib/, then it should be possible to install all of the appropriate target libraries on the host system without a chroot! You "should" just need to configure APT to let you install packages built for that architecture. (I haven't actually tried this; I'm not a Debian user, but I am envious of their multilib).
      - 7y ago

apacheCamel 7y ago

I honestly love coming to HN to see posts like this and comments like yours. It is always so neat to see the other sides of software engineering. You listed 4 acronyms and I have no idea what any of them are or how they fit into this story but all I want to do is deep dive into each one. It is also awesome to see people so interested in things that I've never even encountered before.

zik 7y ago
IRIX [1] was the version of SVR4 UNIX which ran on SGI [2] computers. QEMU [3] is an emulator used to run programs for one machine on another. N64 [4] is the Nintendo 64 games console. SGI Indy [5] was a desktop SGI workstation from 1993. [1] https://en.wikipedia.org/wiki/IRIX https://en.wikipedia.org/wiki/IRIX [2] https://en.wikipedia.org/wiki/Silicon_Graphics https://en.wikipedia.org/wiki/Silicon_Graphics [3] https://www.qemu.org/ https://www.qemu.org/ [4] https://en.wikipedia.org/wiki/Nintendo_64 https://en.wikipedia.org/wiki/Nintendo_64 [5] https://en.wikipedia.org/wiki/SGI_Indy https://en.wikipedia.org/wiki/SGI_Indy
- ehsankia 7y ago
  I love how you use 3 acronyms to describe the first acronym. It's acronyms all the way down!
  - lstamour 7y ago
    SVR4: UNIX System V Release 4 https://en.m.wikipedia.org/wiki/UNIX_System_V https://en.m.wikipedia.org/wiki/UNIX_System_V UNIX: Actually Unix. Not an acronym. https://en.m.wikipedia.org/wiki/Unix https://en.m.wikipedia.org/wiki/Unix
    - tyingq 7y ago
      "Unix. Not an acronym." Sorta. "In 1970, the group coined the name Unics for Uniplexed Information and Computing Service (pronounced "eunuchs"), as a pun on Multics, which stood for Multiplexed Information and Computer Services."

pg_is_a_butt 7y ago

My professional career started working on University owned SGI Indys. I keep that on my resume. Those machines were my favorite. The token ring coax network was prone to disconnects, and the window manager sucked, but they could solve complex math problems way faster than any other machine I had access to. The math department shared them with the Radiology department to process MRIs.

gdubs 7y ago

I wrote to SGI in high school asking for some info on their computers and they sent back a stack of beautifully printed, full-color brochures. The Indy had a webcam, which was very rare in those days. Also included was a brochure on the Indigo workstation, which Industrial Light and Magic used for Jurassic Park, etc. Nintendo is a little mysterious when it comes to what their actual tooling was, but I remember Donkey Kong Country being the first time I read they were using SGIs (or at least the studio "Rare" was). It's somewhat surprising they used the Indy for developing Mario 64 – I always got the sense that it was somewhat lightweight in performance compared to the Indigo, but a very cool machine either way.

mrpippy 7y ago
Those brochures are probably worth real money on eBay if you still have them, a PowerSeries brochure just sold for $200! By the time the Indy came out, the Indigo2 had replaced the Indigo, and I suspect a midrange Indy was a good match for a midrange Indigo1 (at much lower cost). Nintendo made an N64 dev board for the Indy, essentially an N64 on a GIO board, complete with an adapter card to connect controllers.
- goatinaboat 7y ago
  Indy was a good match for a midrange Indigo1 The joke always was that the Indy was the Indigo without the go :-) But it was a decent enough machine to develop on, you didn’t need the 3D stuff if you spent all day in Emacs or compiling. Whereas an Indigo was really targeted at say CAD users.
  - mrpippy 7y ago
    Haha that was because the base Indy was shipping with 16MB of RAM and IRIX 5 was too bloated for that to be usable. Meanwhile everyone with Indigos kept running IRIX 4 until things got better around 5.3. The Indy had XZ graphics available, which I believe were the same as the top Elan option available on the Indigo (4 GEs)
segmondy 7y ago

voltagex_ 7y ago

I wonder if it'll ever be upstreamed.