6 ms·

This is really cool. Is there a practical reason why you would write a game in assembly (speed? portability?)

dllthomas 12y ago
Assembly is about as nonportable as you can get. Hardware access (not exposed by other languages), speed, and possibly executable size are the practical reasons one would write in assembly. The second and third are almost entirely outdated - storage of executables is free relative to storage of data; hardware speeds have made "slow" programs plenty fast for most things; and compilers can do better than you can quickly do, very quickly. The first is still a valid reason to use assembly, but typically in the form of a small snippet of inline assembly in C/C++ code.
- michaelq 12y ago
  Thanks for the in-depth answer. Was there a hardware access issue here, or did you just write this for the challenge/practice?
  - dllthomas 12y ago
    I didn't write this at all, but I assume it was just for hack value, much like the myriad 2048 clones.
- aprdm 12y ago
  Well, in the embedded system field Assembly is still pretty much used everywhere, I think you are talking about doing asm for the regular PC. http://spectrum.ieee.org/static/interactive-the-top-programming-languages#index/0/0/0/1/1/50/1/50/1/50/1/30/1/30/1/30/1/20/1/20/1/5/1/5/1/20/1/100/ http://spectrum.ieee.org/static/interactive-the-top-programm...
  - dllthomas 12y ago
    Does anyone still use assembly for embedded? Of course. Is it a good idea? For some of them, and for the reasons I listed (I suppose I should add "you are working on a legacy assembly codebase"). "Still used pretty much everywhere" is just not the case anymore, even in embedded. At least, that's what the chart seems to say and it matches my experience working alongside embedded developers, knowing some embedded developers I've never had the pleasure of working alongside, and doing a small amount of embedded work myself. (Edited to remove: Right in that link, both C and C++ are used more than assembly in the embedded space, and Arduino (more C/C++) follows closely behind assembly. The chart is unclear, but the rankings seem to be based on numbers that don't change when different filters are applied, which would mean that it does not show this. It is still certainly consistent with "assembly no longer dominates embedded", though - some of the C and C++ will be embedded, and all of the Arduino will be embedded.)
- deleted 12y ago
  [deleted]
- bnegreve 12y ago
  > Hardware access (not exposed by other languages), speed, and possibly executable size are the practical reasons one would write in assembly. This is a bit misleading, accesses to physical memory, disks and to other devices are usually protected by the operating system, not by the language. So you don't have direct hardware access because you program in assembly, but because you run a program without the control of an operating system. This can be done in assembly, but also in C or in any other language that can generate native code. The only thing that you can do with assembly and that you can't really do with higher level language like C is accessing processor specific registers/instruction sets (e.g. SSE). And this is typically done using inline assembly snippets, as there is no reason to write a whole program in assembly when you only need to optimize a single function. So I would say that having better hardware access is not a good reason to write an entire program in assembly. On the other hand, building small, standalone executable file that use very little (stack) memory is still relevant for programs that run on very small (usually embedded) hardware. Especially when they need to run fast or to have low energy consumption. So speed and memory usage are still pretty good reasons to use assembly :)
  - dllthomas 12y ago
    Hmm, I guess there is some room for misinterpretation. First, you seem to think I was answering a slightly different question - "In what circumstances should I make the decision to write assembly?" The question I was answering was closer to "When people need to write assembly, why?" The actual question, of course, was not quite either of those. Also, addressing a point of ambiguity: I did not mean "hardware access ([this is something that is] not exposed by other languages)" - that is, in general, wrong. I meant "hardware access ([when the particular thing is] not exposed by other languages)". This includes SSE (though that is starting to be included as builtins in some compilers). Outside of SSE, I grant that there isn't much on x86 platforms that is relevant to a game, since games on x86 platforms typically run under an OS. It can be relevant if you're writing a driver, though. And this can vary substantially by platform. And no, it's not a good reason to write an entire program in assembly unless a sufficient percentage of your program is calls to these things that the C inlines are just adding cruft. "On the other hand, building small, standalone executable file that use very little (stack) memory is still relevant for programs that run on very small (usually embedded) hardware. Especially when they need to run fast or to have low energy consumption. So speed and memory usage are still pretty good reasons to use assembly :)" No, that is substantially more misleading. Like I said, you cannot quickly do better than a modern compiler, and a compiler does it very, very quick.
cyorir 12y ago
The person who wrote this wrote it to be booted directly from BIOS. That means it must handle everything an OS would otherwise do for it: bootloader, resource management, hardware access, random number generation, etc. So a project like this has great value as an introduction to low level systems and OS development.
- gizmo686 12y ago
  As someone who has written no-os code, you do not need to do everything the OS does. If you do not mind giving up most of your RAM, you can stick to realmode and take advantage of the BIOS functions (you can work around the RAM limitation by jumping between modes). If your computer has UEFI, you have access to a much more advanced set of functions, and (for many purposes) can target that. I haven't done anything beyond hello world type stuff on UEFI, but it feels like you can get alot done without noticing the lack of an OS.
  - wtallis 12y ago
    UEFI is awesome in terms of what it enables you to do without an OS, but once you install a few tools like an EFI shell, it's at least as much of an OS as DOS ever was.

Assembly is about as nonportable as you can get. Hardware access (not exposed by other languages), speed, and possibly executable size are the practical reasons one would write in assembly. The second and third are almost entirely outdated - storage of executables is free relative to storage of data; hardware speeds have made "slow" programs plenty fast for most things; and compilers can do better than you can quickly do, very quickly. The first is still a valid reason to use assembly, but typically in the form of a small snippet of inline assembly in C/C++ code.

michaelq 12y ago
Thanks for the in-depth answer. Was there a hardware access issue here, or did you just write this for the challenge/practice?
- dllthomas 12y ago
  I didn't write this at all, but I assume it was just for hack value, much like the myriad 2048 clones.
aprdm 12y ago
Well, in the embedded system field Assembly is still pretty much used everywhere, I think you are talking about doing asm for the regular PC. http://spectrum.ieee.org/static/interactive-the-top-programming-languages#index/0/0/0/1/1/50/1/50/1/50/1/30/1/30/1/30/1/20/1/20/1/5/1/5/1/20/1/100/ http://spectrum.ieee.org/static/interactive-the-top-programm...
- dllthomas 12y ago
  Does anyone still use assembly for embedded? Of course. Is it a good idea? For some of them, and for the reasons I listed (I suppose I should add "you are working on a legacy assembly codebase"). "Still used pretty much everywhere" is just not the case anymore, even in embedded. At least, that's what the chart seems to say and it matches my experience working alongside embedded developers, knowing some embedded developers I've never had the pleasure of working alongside, and doing a small amount of embedded work myself. (Edited to remove: Right in that link, both C and C++ are used more than assembly in the embedded space, and Arduino (more C/C++) follows closely behind assembly. The chart is unclear, but the rankings seem to be based on numbers that don't change when different filters are applied, which would mean that it does not show this. It is still certainly consistent with "assembly no longer dominates embedded", though - some of the C and C++ will be embedded, and all of the Arduino will be embedded.)
deleted 12y ago
[deleted]
bnegreve 12y ago
> Hardware access (not exposed by other languages), speed, and possibly executable size are the practical reasons one would write in assembly. This is a bit misleading, accesses to physical memory, disks and to other devices are usually protected by the operating system, not by the language. So you don't have direct hardware access because you program in assembly, but because you run a program without the control of an operating system. This can be done in assembly, but also in C or in any other language that can generate native code. The only thing that you can do with assembly and that you can't really do with higher level language like C is accessing processor specific registers/instruction sets (e.g. SSE). And this is typically done using inline assembly snippets, as there is no reason to write a whole program in assembly when you only need to optimize a single function. So I would say that having better hardware access is not a good reason to write an entire program in assembly. On the other hand, building small, standalone executable file that use very little (stack) memory is still relevant for programs that run on very small (usually embedded) hardware. Especially when they need to run fast or to have low energy consumption. So speed and memory usage are still pretty good reasons to use assembly :)
- dllthomas 12y ago
  Hmm, I guess there is some room for misinterpretation. First, you seem to think I was answering a slightly different question - "In what circumstances should I make the decision to write assembly?" The question I was answering was closer to "When people need to write assembly, why?" The actual question, of course, was not quite either of those. Also, addressing a point of ambiguity: I did not mean "hardware access ([this is something that is] not exposed by other languages)" - that is, in general, wrong. I meant "hardware access ([when the particular thing is] not exposed by other languages)". This includes SSE (though that is starting to be included as builtins in some compilers). Outside of SSE, I grant that there isn't much on x86 platforms that is relevant to a game, since games on x86 platforms typically run under an OS. It can be relevant if you're writing a driver, though. And this can vary substantially by platform. And no, it's not a good reason to write an entire program in assembly unless a sufficient percentage of your program is calls to these things that the C inlines are just adding cruft. "On the other hand, building small, standalone executable file that use very little (stack) memory is still relevant for programs that run on very small (usually embedded) hardware. Especially when they need to run fast or to have low energy consumption. So speed and memory usage are still pretty good reasons to use assembly :)" No, that is substantially more misleading. Like I said, you cannot quickly do better than a modern compiler, and a compiler does it very, very quick.

cyorir 12y ago

The person who wrote this wrote it to be booted directly from BIOS. That means it must handle everything an OS would otherwise do for it: bootloader, resource management, hardware access, random number generation, etc. So a project like this has great value as an introduction to low level systems and OS development.

gizmo686 12y ago
As someone who has written no-os code, you do not need to do everything the OS does. If you do not mind giving up most of your RAM, you can stick to realmode and take advantage of the BIOS functions (you can work around the RAM limitation by jumping between modes). If your computer has UEFI, you have access to a much more advanced set of functions, and (for many purposes) can target that. I haven't done anything beyond hello world type stuff on UEFI, but it feels like you can get alot done without noticing the lack of an OS.
- wtallis 12y ago
  UEFI is awesome in terms of what it enables you to do without an OS, but once you install a few tools like an EFI shell, it's at least as much of an OS as DOS ever was.