6 ms·

The amount of inline assembly in this code is wild.

naikrovek 5y ago
well, it was authored for the PS2 and GameCube, I think. for those platforms I imagine you'd need to use assembly at least a little to get the desired performance.
- Pxtl 5y ago
  Yeah, I remember DreamSNES on the Dreamcast ran like a dog, so not surprised that a lot of assembler is needed to make it work on platforms of that era.
  - sli 5y ago
    The original bsnes back in the day (before higan and the modern bsnes) required quite a high end machine to run playably in accuracy mode so yeah, this all tracks.
  - anthk 5y ago
    The 90 MHZ CPU for the dreamcast is not that powerful. A Pentium MMX would barely run ZSNES with a frameskip value of 2, 8000 hz audio and the lowest supported res.
- AdmiralAsshat 5y ago
  It's actually pretty wild to me that as late as 2001 or so, developers would still be writing assembly code to get games on consoles to run properly. Like, at what point did the industry graduate to, I dunno, C?
  - Wowfunhappy 5y ago
    I mean, they're still mostly using C. You can find inline assembly even today in e.g. video decoders like x264. Not a ton of course, but they do use it.
    - klodolph 5y ago
      x264 relies heavily on files written entirely in assembly, not just inline assembly. Example: https://github.com/mirror/x264/blob/master/common/x86/dct-64.asm https://github.com/mirror/x264/blob/master/common/x86/dct-64...
      - Wowfunhappy 5y ago
        Oh—even better! So yeah, we still use assembly in the places where it’s absolutely performance critical, it’s not inherently anachronistic.
  - derefr 5y ago
    AFAIK, that transition wasn't complete until the current-minus-one gen (PS4/XBO/Wii U). This was also roughly the point when consoles switched from "rebooting into" games (i.e. console SDKs being library exokernels that games pulled in; making each game, essentially, a unikernel — previously running on bare metal, later running under a hypervisor whose dom0 runs on a separate core) into finally having enough processing headroom that games could just now be regular user-mode applications running as processes under a pre-emptive OS scheduler.
    - klodolph 5y ago
      There are various Nintendo 64 codebases you can find, such as the Turok 64 source code (which was taken from a workstation sold on eBay, of all places). Generally speaking, they're written in C. I haven't encountered hand-written assembly outside the SDK. I know of a couple games that do use custom RSP microcode but those games are the exception. The original Xbox shipped with an OS, and games ran under that OS. The OS gave itself a fixed time slice every frame. My understanding is that Microsoft was a bit quicker to move to a "normal" type of OS on their consoles, and the other vendors were a bit slower, but I think PS3 / Wii software ran under the console's OS as well, rather than the Unikernel style from the previous generation. The Xbox system software was forked from Windows 2000 (and heavily modified). I guess it depends on what you mean by "regular user-mode applications". The PS3 runs what is believed to be a fork of FreeBSD. The Wii had system software, and new games shipped with a copy of the latest software bundled (so you would still get updates without a network connection).
      - BBC-vs-neolibs 5y ago
      - kevingadd 5y ago
        Yes and no, for example Morrowind on the Xbox used a trick where it would silently reboot your console at loading screens to free up memory, and the console would boot directly into the game. https://kotaku.com/morrowind-completely-rebooted-your-xbox-during-some-loa-1845158550 https://kotaku.com/morrowind-completely-rebooted-your-xbox-d... You could certainly still say that the 'game ran under the OS' in this case since the kernel and drivers were underneath it, but I think it's fair to consider that a different beast from more modern consoles that have a full OS available underneath that you can summon with the home button and does things in the background like maintain a persistent network connection, do background downloads, etc.
  - naikrovek 5y ago
    really? just 5 years or so earlier the sentiment among the majority of game developers that I spoke to was something like "today, real games are written in assembly, and toys are written in C, though that's changing." for a long time, the only way to get performance out of code was to write the most-used bits in assembly. even today there are some things, just a few, which still need to be in assembly if you really want to squeeze out all the performance that you can. most people just make a tradeoff elsewhere to get the performance, rather than using assembly. just 25 years ago the game industry was filled with people extremely knowledgeable in assembly. yet today it is viewed as a black art. sad.
    - eru 5y ago
      > just 25 years ago the game industry was filled with people extremely knowledgeable in assembly. yet today it is viewed as a black art. sad. Why is that sad? It looks like progress to me. Economizing on inputs is how productivity improvements look like. Human capital is an input like any other. Similar considerations apply to more boring enterprise software development too: most developers these days could probably not write a hashtable from scratch. And that's good! We have libraries for that. Thus the industry is much more accessible to more people. (I do understand the temptation of nostalgia.)
      - naikrovek 5y ago
        >> just 25 years ago the game industry was filled with people extremely knowledgeable in assembly. yet today it is viewed as a black art. sad. > Why is that sad? It looks like progress to me. It is progress, yes, and I wonder where compiler authors are going to come from in the future. If we forget how to write in assembly, we forget how to tell computers how to do it. I think of it by way of analogy: I can buy bottles of water in the store, so why do I still want drinkable water from my tap? Bottled water is progress, and drinkable water from the tap is "the old way." The old ways are important. Especially when they are the foundations of our modern technical society like compilers are. It is true that new people can learn assembly when it comes time for them to write a compiler, or contribute to one, and as the number of assembly authors falls, the fewer opinions we will have about things, and the more monolithic things will be. When lots of people are part of a community, there is great diversity of thought in that community. If it's just a few (hundred?) people who speak assembly, the diversity of thought, and thus innovation in compilers will be almost nil. It is literally better for everyone if there are more who can write assembly well. Secondly, people are avoiding learning assembly because they are afraid of it, which makes some sense to me at first glance, and makes no sense to me after writing some assembly. There is literally nothing scary about assembly; it just SEEMS scary. It can be quite fun to see just how little it takes to do things, and then observing just how unbelievably fast those programs are when run. Part of the sadness I mention above is just "old man yells at cloud," but some of it is, I believe, bad for us in the long term if assembly does truly become a black art.
  - qbasic_forever 5y ago
    Back in the era of these consoles they were using pretty exotic architectures, like the PS2 emotion engine with a MIPS CPU and wacky parallel vector/GPU processing engine (along with a whole PS1 CPU bolted on to poll inputs and other tasks). You didn't really get good C library support and were extremely lucky to even have a good C compiler and library in the early days of their launch. It wasn't like GCC had a command line flag to flip and suddenly get an optimized PS2 compatible binary built.
    - anthk 5y ago
      Well, you had libre SDK's and the 300mhz MIPS CPU for the PS2 is more than capable to emulate the SNES almost well, kinda on par on a Pentium II/ 450 MHZ III.
amyjess 5y ago
Which is pretty common for old-school emulators. ZSNES was written in x86 assembly, and Kega-Fusion was mostly assembly except for the UX in C. Both of these were, for a long time, the most popular emulators for their systems. Thankfully ZSNES hasn't been relevant for some time, though Kega-Fusion is still a big deal because the Sega emulation scene is a mess (I think BizHawk is the only other decent Genesis emulator with Sega CD and 32X support). Hopefully Ares will catch up one day and put everything else out to pasture.
Kye 5y ago
Common for the era. I still remember the ad looking for C and assembly programmers at the end of the credit roll on the original Wing Commander (1990).

well, it was authored for the PS2 and GameCube, I think. for those platforms I imagine you'd need to use assembly at least a little to get the desired performance.

Pxtl 5y ago
Yeah, I remember DreamSNES on the Dreamcast ran like a dog, so not surprised that a lot of assembler is needed to make it work on platforms of that era.
- sli 5y ago
  The original bsnes back in the day (before higan and the modern bsnes) required quite a high end machine to run playably in accuracy mode so yeah, this all tracks.
- anthk 5y ago
  The 90 MHZ CPU for the dreamcast is not that powerful. A Pentium MMX would barely run ZSNES with a frameskip value of 2, 8000 hz audio and the lowest supported res.
AdmiralAsshat 5y ago
It's actually pretty wild to me that as late as 2001 or so, developers would still be writing assembly code to get games on consoles to run properly. Like, at what point did the industry graduate to, I dunno, C?
- Wowfunhappy 5y ago
  I mean, they're still mostly using C. You can find inline assembly even today in e.g. video decoders like x264. Not a ton of course, but they do use it.
  - klodolph 5y ago
    x264 relies heavily on files written entirely in assembly, not just inline assembly. Example: https://github.com/mirror/x264/blob/master/common/x86/dct-64.asm https://github.com/mirror/x264/blob/master/common/x86/dct-64...
    - Wowfunhappy 5y ago
      Oh—even better! So yeah, we still use assembly in the places where it’s absolutely performance critical, it’s not inherently anachronistic.
- derefr 5y ago
  AFAIK, that transition wasn't complete until the current-minus-one gen (PS4/XBO/Wii U). This was also roughly the point when consoles switched from "rebooting into" games (i.e. console SDKs being library exokernels that games pulled in; making each game, essentially, a unikernel — previously running on bare metal, later running under a hypervisor whose dom0 runs on a separate core) into finally having enough processing headroom that games could just now be regular user-mode applications running as processes under a pre-emptive OS scheduler.
  - klodolph 5y ago
    There are various Nintendo 64 codebases you can find, such as the Turok 64 source code (which was taken from a workstation sold on eBay, of all places). Generally speaking, they're written in C. I haven't encountered hand-written assembly outside the SDK. I know of a couple games that do use custom RSP microcode but those games are the exception. The original Xbox shipped with an OS, and games ran under that OS. The OS gave itself a fixed time slice every frame. My understanding is that Microsoft was a bit quicker to move to a "normal" type of OS on their consoles, and the other vendors were a bit slower, but I think PS3 / Wii software ran under the console's OS as well, rather than the Unikernel style from the previous generation. The Xbox system software was forked from Windows 2000 (and heavily modified). I guess it depends on what you mean by "regular user-mode applications". The PS3 runs what is believed to be a fork of FreeBSD. The Wii had system software, and new games shipped with a copy of the latest software bundled (so you would still get updates without a network connection).
    - BBC-vs-neolibs 5y ago
    - kevingadd 5y ago
      Yes and no, for example Morrowind on the Xbox used a trick where it would silently reboot your console at loading screens to free up memory, and the console would boot directly into the game. https://kotaku.com/morrowind-completely-rebooted-your-xbox-during-some-loa-1845158550 https://kotaku.com/morrowind-completely-rebooted-your-xbox-d... You could certainly still say that the 'game ran under the OS' in this case since the kernel and drivers were underneath it, but I think it's fair to consider that a different beast from more modern consoles that have a full OS available underneath that you can summon with the home button and does things in the background like maintain a persistent network connection, do background downloads, etc.
- naikrovek 5y ago
  really? just 5 years or so earlier the sentiment among the majority of game developers that I spoke to was something like "today, real games are written in assembly, and toys are written in C, though that's changing." for a long time, the only way to get performance out of code was to write the most-used bits in assembly. even today there are some things, just a few, which still need to be in assembly if you really want to squeeze out all the performance that you can. most people just make a tradeoff elsewhere to get the performance, rather than using assembly. just 25 years ago the game industry was filled with people extremely knowledgeable in assembly. yet today it is viewed as a black art. sad.
  - eru 5y ago
    > just 25 years ago the game industry was filled with people extremely knowledgeable in assembly. yet today it is viewed as a black art. sad. Why is that sad? It looks like progress to me. Economizing on inputs is how productivity improvements look like. Human capital is an input like any other. Similar considerations apply to more boring enterprise software development too: most developers these days could probably not write a hashtable from scratch. And that's good! We have libraries for that. Thus the industry is much more accessible to more people. (I do understand the temptation of nostalgia.)
    - naikrovek 5y ago
      >> just 25 years ago the game industry was filled with people extremely knowledgeable in assembly. yet today it is viewed as a black art. sad. > Why is that sad? It looks like progress to me. It is progress, yes, and I wonder where compiler authors are going to come from in the future. If we forget how to write in assembly, we forget how to tell computers how to do it. I think of it by way of analogy: I can buy bottles of water in the store, so why do I still want drinkable water from my tap? Bottled water is progress, and drinkable water from the tap is "the old way." The old ways are important. Especially when they are the foundations of our modern technical society like compilers are. It is true that new people can learn assembly when it comes time for them to write a compiler, or contribute to one, and as the number of assembly authors falls, the fewer opinions we will have about things, and the more monolithic things will be. When lots of people are part of a community, there is great diversity of thought in that community. If it's just a few (hundred?) people who speak assembly, the diversity of thought, and thus innovation in compilers will be almost nil. It is literally better for everyone if there are more who can write assembly well. Secondly, people are avoiding learning assembly because they are afraid of it, which makes some sense to me at first glance, and makes no sense to me after writing some assembly. There is literally nothing scary about assembly; it just SEEMS scary. It can be quite fun to see just how little it takes to do things, and then observing just how unbelievably fast those programs are when run. Part of the sadness I mention above is just "old man yells at cloud," but some of it is, I believe, bad for us in the long term if assembly does truly become a black art.
- qbasic_forever 5y ago
  Back in the era of these consoles they were using pretty exotic architectures, like the PS2 emotion engine with a MIPS CPU and wacky parallel vector/GPU processing engine (along with a whole PS1 CPU bolted on to poll inputs and other tasks). You didn't really get good C library support and were extremely lucky to even have a good C compiler and library in the early days of their launch. It wasn't like GCC had a command line flag to flip and suddenly get an optimized PS2 compatible binary built.
  - anthk 5y ago
    Well, you had libre SDK's and the 300mhz MIPS CPU for the PS2 is more than capable to emulate the SNES almost well, kinda on par on a Pentium II/ 450 MHZ III.

amyjess 5y ago

Which is pretty common for old-school emulators. ZSNES was written in x86 assembly, and Kega-Fusion was mostly assembly except for the UX in C. Both of these were, for a long time, the most popular emulators for their systems. Thankfully ZSNES hasn't been relevant for some time, though Kega-Fusion is still a big deal because the Sega emulation scene is a mess (I think BizHawk is the only other decent Genesis emulator with Sega CD and 32X support). Hopefully Ares will catch up one day and put everything else out to pasture.

Kye 5y ago

Common for the era. I still remember the ad looking for C and assembly programmers at the end of the credit roll on the original Wing Commander (1990).