6 ms·

Why is this getting downvoted? Writing programs in pure assembly does offer the possibility of implementing very fine-grained optimisations. However, assembly i

• projektfu 7y ago
  The biggest benefit is usually that you can forgo calling conventions in your own code because everything is visible to you. Of course the code starts looking like spaghetti.
  • ajxs 7y ago
    This is correct. You can forego all aspects of your platform's calling conventions if you so desire. Omitting setting up stack frames is a really simple optimisation that can be done in hand-written assembly. You've already touched on what the stakes of doing such things are.
  • jfkebwjsbx 7y ago
    Compilers are able to do the same since a few years.
    • projektfu 7y ago
      Yes, but they rarely take a whole-program approach. Reducing a complicated sequence of function calls to a few goto’s is not an easy task. Probably NP-hard?
      • BubRoss 7y ago
        Doing it on a whole program basis is also unlikely to give much benefit. Function calls are extremely fast, they only show their overhead in tight loops.
        • projektfu 7y ago
          Yeah, reviewing the repository there’s a lot of high level language code now, so that probably removes most of the benefit of assembly. You’re still calling into the OS a lot. Some of the other low level systems (like the Mac) had a trap system that wasn’t so far away in cycle count from user code. But in these days of needing 10,000 cycles to bridge a system call it’s best to do whatever you can to avoid calling the OS.
          • BubRoss 7y ago
            Function inlining can't avoid system calls
            • projektfu 7y ago
              Exactly my point
• wenc 7y ago
  Just curious, is pure assembly harder to test for correctness? Are there higher level abstractions like functions?
  • ajxs 7y ago
    Programs don't have to be particularly large complex to become relatively unweildy and difficult to understand in assembly. I find it takes me much more time to comprehend large portions of written assembly than higher-level languages. Your mileage may vary. Other engineers might be more talented than I am in this regard, however I think this is more or less everyone's experience. Abstractions like functions are still present, just not in the way that you might think of them in a higher-level language. You use 'branching' instructions to jump from one part of the code to another. Either by referencing labeled sections of the code to perform 'absolute' jumps, or by jumping 'relative' to the current instruction. This forms the building blocks that can be used to implement more abstract constructs such as loops, functions and conditionals. This is a gross simplification, I hope it helps answer your question though.
  • pjmlp 7y ago
    Yes and no. You can write tests like in any language, they just happen to be more tedious. If you make use of powerful macro assemblers, like MASM and TASM, you can write what looks like high level functions. You can have a look here for a couple of MASM examples, https://de.wikipedia.org/wiki/Microsoft_Macro_Assembler https://de.wikipedia.org/wiki/Microsoft_Macro_Assembler
  • misja111 7y ago
    You can code anything you want in ASM, so higher level abstractions as well. However while doing that you will lose some of the performance gain that ASM gives you. Optimised ASM can still be tested but one problem is that when the code doesn't work, it can simply crash. This makes it a pain to debug.
• crispinb 7y ago
  > Why is this getting downvoted? You might as well ask why dogs bark or puzzle with furrowed brow over the croaking of frogs.
  • ludditetech 7y ago
    haha
• m463 7y ago
  I was thinking the same thing. Then I sort of turned the problem around in my mind. When is a compiler prevented from optimizing? Maybe pointer aliasing? Another thing I wondered. I've written hello.c and it's about 84 bytes of C and 8.3k as an executable. Would hand-coded assembler be that large? maybe it's that compilers CAN do well, but because of requirements, they can't do some things well and necessarily create a lot of "boilerplate infrastructure".
  • jsjohnst 7y ago
    > I've written hello.c and it's about 84 bytes of C and 8.3k as an executable. Would hand-coded assembler be that large? The answer is generally no. A lot of that overhead is due to the C std library. If memory serves from a blog post I read long ago, with very very aggressive tuning, you can get a hello world binary down under 50 bytes (which is smaller than the ELF header). A “normal” ASM coded “hello world” binary could easily be in the range of a few hundred bytes without anything special.
    • m463 7y ago
      I looked a little further. hello.c: 4 loc, 84 bytes hello.s: 30 loc, 517 bytes hello: 8.3k so it must be data structures for linking. oh, and if I use -static, hello becomes 844704 bytes. :)
    • ajxs 7y ago
      You can use the `-S` switch with gcc to produce the intermediate assembler representation of your C program instead of binary output. From there you can see for yourself what optimisation has been performed and what hand optimisations are possible. I just compiled my own 'hello.c' on Linux, with the optimisation flag set for 'code size', and the binary weighed in around 8.3k. I then removed the `printf` call and the inclusion of `stdio.h`. The resulting binary was 8.1k. This is exactly as expected. Why would the inclusion of a call to a dynamic library bloat the final binary size?
      • jsjohnst 7y ago
        > Why would the inclusion of a call to a dynamic library bloat the final binary size? Here’s two good links to read on it: https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html https://www.muppetlabs.com/~breadbox/software/tiny/teensy.ht... http://timelessname.com/elfbin/ http://timelessname.com/elfbin/