6 ms·

It's not that hard to write assembly. Tedious is the word I would use. Learn how to express the basic operators of C in assembly (functions and parameters with

by retrac 4y ago

It's not that hard to write assembly. Tedious is the word I would use. Learn how to express the basic operators of C in assembly (functions and parameters with the stack, do/while/if/for, array and struct indexing) and then write everything in pseudo-C and hand translate it to assembly. Writing optimized assembly is a whole other question. But some variant of the above - pseudo-code or flowcharting, followed by close translation into assembly, is how most software in assembly was written, back in the day. Assuming your program logic is correct to begin with, it's almost mindless. So mindless you could program a computer to do it.

waynesonfire 4y ago
do you have any examples of the flowcharts used for asm writing? i also recall someone using an excel spreadsheet when writing for itanium.
- retrac 4y ago
  https://www.ibiblio.org/apollo/Documents/GeminiMinnickMathFlow.pdf https://www.ibiblio.org/apollo/Documents/GeminiMinnickMathFl... (large PDF) This is the flight software used in the Gemini spacecraft (1960s). The actual assembly code did not survive. It was considered sort of incidental. For the designers and coders then, the flowcharts were the program, the real source. There's more information about the Gemini software and how the programmers worked here: https://www.ibiblio.org/apollo/Gemini.html#Evolution_of_the_Flight_Software https://www.ibiblio.org/apollo/Gemini.html#Evolution_of_the_...
  - titzer 4y ago
    Wow, that diagram is absolutely wild! Thanks for sharing. Handwritten flowcharts and most of the code is actually math formulas and matrix computations.
  - pests 4y ago
    I just read that entire page, amazing stuff.
- pdpi 4y ago
  Just literally draw a flowchart of what your program is supposed to do, then translate that flowchart. Something like each box gets its own label, diamonds are just some variation on `jz some-box-label`, etc. The problem with assembly isn't that it's too complex, it's that it's way too simple, so it's exceedingly easy to lose track of how your higher-level thought process maps to assembly code. The flowchart serves as an intermediate representation between the two — something you can reason about at a high level, but can almost mindlessly, mechanically translate to assembly.
kevincox 4y ago
It's not that hard to write assembly. It is hard to write good assembly. In order to produce maintainable software you need incredible discipline (and probably some advice what that discipline should be). To a large extent you can consider high level languages opinionated. They have decided how to pass arguments, how to return values and how to lay out memory. The programmer no longer needs to think about these things, and they can't mess them up if they try. Doing this yourself you need to pick to those conventions and stick to them if you want maintainable software. Of course the benefit of assembly is that it is trivial to break those conventions when there is good reason (optimization for example) but then you will pay the price of more difficult maintenance for that unconventional code.
- labrador 4y ago
  I was hired to write assembly (68000) so I didn't know any better. I liked developing the discipline and the knowledge of the machine. I still miss it sometimes. But like another comment said, it's tedious, so I wouldn't go back to it.
- retrac 4y ago
  Great point. The only time I've been required (rather than for fun/hobby purposes) to write assembly was for a controller where we didn't have a C compiler. Like I hinted, I followed the approach of writing in C (including testing it as much as possible on my desktop in C) and then hand-translating precisely because of what you mention -- by default there's no structure. I basically adopted the structures and conventions of the C language and C compilers and imposed them on my assembly code, since I was familiar with those, and know how to make working software using them. You could use another language's conventions. Or you could veer off into the wild, but there be dragons.
titzer 4y ago
Writing is almost never the issue. It's debugging that is the absolute nightmare, because it is so tedious to reconstruct what happened in terms of low-level things. Without names, data structures, functions, human memory quickly becomes overwhelmed. The most complicated assembly I've written recently is a fast Wasm interpreter. The only way I could tackle it effectively was to write the implementation of just one or two bytecodes at a time, test them thoroughly and in isolation. We're talking about writing only a handful of instructions per commit. There's just no way you can debug much more than that at a time. You need to build little bricks of fully-working code and stack them, ratcheting up the progress, so that when something breaks, most of the things you don't need to debug.
- artemonster 4y ago
  I find debugging assembly a breeze IF you have a full trace of all registers (ie in a simulation)
  - dmoy 4y ago
    Well, and you remember what all the registers do. I once burned a couple hours on a microcontroller because I had transposed bits 5 & 4 on some register that dictated a certain i/o behavior and caused things to be really weird. One register out of like 11 registers that affected how that i/o operated, one bit transposed, whole thing was inscrutable.
    - MichaelZuo 4y ago
      It seems like having a diagram would help a lot, maybe some kind of 2D AutoCAD with a visual representation and their logical relationships? Or a Verilog for software?
- emrah 4y ago
  > Writing is almost never the issue. It's debugging that is the absolute nightmare, because it is so tedious to reconstruct what happened in terms of low-level things. Without names, data structures, functions, human memory quickly becomes overwhelmed. People claim GPT is creative and when I disagree, they say mixing to come up with a new combo is creative and that humans do it for creativity too While that might be true, what's even better is if GPT could read assembly code, find things that can be fixed and optimized and write new more optimal better code. Of course this can be done in any language. If we could get GPT to optimize our code libraries to reduce code size, memory footprint etc that would be a huge win for humanity and also show creativity. In short, it should tackle the "why is hello world app in X language taking up 100MB" problem :)
delta_p_delta_x 4y ago
> Writing optimized assembly is a whole other question. To be fair, that's the compiler's job; everything from dead-code elimination to loop auto-vectorisation and auto-parallelisation is pretty hard when done manually.

by retrac 4y ago

waynesonfire 4y ago

do you have any examples of the flowcharts used for asm writing? i also recall someone using an excel spreadsheet when writing for itanium.

retrac 4y ago
https://www.ibiblio.org/apollo/Documents/GeminiMinnickMathFlow.pdf https://www.ibiblio.org/apollo/Documents/GeminiMinnickMathFl... (large PDF) This is the flight software used in the Gemini spacecraft (1960s). The actual assembly code did not survive. It was considered sort of incidental. For the designers and coders then, the flowcharts were the program, the real source. There's more information about the Gemini software and how the programmers worked here: https://www.ibiblio.org/apollo/Gemini.html#Evolution_of_the_Flight_Software https://www.ibiblio.org/apollo/Gemini.html#Evolution_of_the_...
- titzer 4y ago
  Wow, that diagram is absolutely wild! Thanks for sharing. Handwritten flowcharts and most of the code is actually math formulas and matrix computations.
- pests 4y ago
  I just read that entire page, amazing stuff.
pdpi 4y ago
Just literally draw a flowchart of what your program is supposed to do, then translate that flowchart. Something like each box gets its own label, diamonds are just some variation on `jz some-box-label`, etc. The problem with assembly isn't that it's too complex, it's that it's way too simple, so it's exceedingly easy to lose track of how your higher-level thought process maps to assembly code. The flowchart serves as an intermediate representation between the two — something you can reason about at a high level, but can almost mindlessly, mechanically translate to assembly.

kevincox 4y ago

It's not that hard to write assembly. It is hard to write good assembly. In order to produce maintainable software you need incredible discipline (and probably some advice what that discipline should be). To a large extent you can consider high level languages opinionated. They have decided how to pass arguments, how to return values and how to lay out memory. The programmer no longer needs to think about these things, and they can't mess them up if they try. Doing this yourself you need to pick to those conventions and stick to them if you want maintainable software. Of course the benefit of assembly is that it is trivial to break those conventions when there is good reason (optimization for example) but then you will pay the price of more difficult maintenance for that unconventional code.

labrador 4y ago
I was hired to write assembly (68000) so I didn't know any better. I liked developing the discipline and the knowledge of the machine. I still miss it sometimes. But like another comment said, it's tedious, so I wouldn't go back to it.
retrac 4y ago
Great point. The only time I've been required (rather than for fun/hobby purposes) to write assembly was for a controller where we didn't have a C compiler. Like I hinted, I followed the approach of writing in C (including testing it as much as possible on my desktop in C) and then hand-translating precisely because of what you mention -- by default there's no structure. I basically adopted the structures and conventions of the C language and C compilers and imposed them on my assembly code, since I was familiar with those, and know how to make working software using them. You could use another language's conventions. Or you could veer off into the wild, but there be dragons.

titzer 4y ago

Writing is almost never the issue. It's debugging that is the absolute nightmare, because it is so tedious to reconstruct what happened in terms of low-level things. Without names, data structures, functions, human memory quickly becomes overwhelmed. The most complicated assembly I've written recently is a fast Wasm interpreter. The only way I could tackle it effectively was to write the implementation of just one or two bytecodes at a time, test them thoroughly and in isolation. We're talking about writing only a handful of instructions per commit. There's just no way you can debug much more than that at a time. You need to build little bricks of fully-working code and stack them, ratcheting up the progress, so that when something breaks, most of the things you don't need to debug.

artemonster 4y ago
I find debugging assembly a breeze IF you have a full trace of all registers (ie in a simulation)
- dmoy 4y ago
  Well, and you remember what all the registers do. I once burned a couple hours on a microcontroller because I had transposed bits 5 & 4 on some register that dictated a certain i/o behavior and caused things to be really weird. One register out of like 11 registers that affected how that i/o operated, one bit transposed, whole thing was inscrutable.
  - MichaelZuo 4y ago
    It seems like having a diagram would help a lot, maybe some kind of 2D AutoCAD with a visual representation and their logical relationships? Or a Verilog for software?
emrah 4y ago
> Writing is almost never the issue. It's debugging that is the absolute nightmare, because it is so tedious to reconstruct what happened in terms of low-level things. Without names, data structures, functions, human memory quickly becomes overwhelmed. People claim GPT is creative and when I disagree, they say mixing to come up with a new combo is creative and that humans do it for creativity too While that might be true, what's even better is if GPT could read assembly code, find things that can be fixed and optimized and write new more optimal better code. Of course this can be done in any language. If we could get GPT to optimize our code libraries to reduce code size, memory footprint etc that would be a huge win for humanity and also show creativity. In short, it should tackle the "why is hello world app in X language taking up 100MB" problem :)

delta_p_delta_x 4y ago

> Writing optimized assembly is a whole other question. To be fair, that's the compiler's job; everything from dead-code elimination to loop auto-vectorisation and auto-parallelisation is pretty hard when done manually.