What is the best way to organize a big project on a fasm so as not to get lost in logic? (16-18 thousand lines of code)? Macro tools to create your own language to make it clearer? Graphically build a dependency graph? maybe something else? (Please do not offer C and other languages, please, such are the features of the project, which is exactly the fasm needed)

  • Oh. I do not envy you. And to convince the leadership about C is not at all destiny? - VladD
  • one
    Nothing is better than commenting on each block with a code or pseudocode (in short, playing a human compiler), well, it does not occur to split everything into a bunch of library modules. I hope you get paid well for it. But I would recommend to take a normal language, and for those who want a strange exhaust decompile and present in the form of a source code in assembler. Or change the project. - drdaeman
  • four
    Darkness. Maybe it's time to leave this company cheerful perverts? What kind of project is it that you need to write everything in assembler? Any firmware for a microcontroller? - skegg
  • @mikillskegg, fasm, as far as I know, for x86 / x86_64. - drdaeman
  • I'm thinking here ... 20 KSLOC in x86 assembler is, according to very rough estimates, 0.5-4 KSLOC in modern high-level languages. If there is a part that in some unknown way requires the toughest real-time, where you have to take the processor clock cycles right here - well, you can build it in assembly language and authenticate it. To make part of the prototype in the evenings in any language that implies rapid development (choosing the language for the task), yes, complete the situation, put before the fact that this was done in a couple of evenings, and the assembler still plow and plow. - drdaeman

2 answers 2

  1. Design from top to bottom.
  2. Breaking the code into modules and procedures
  3. If possible, avoid side effects (for example, minimize the use of global variables).
  4. Comments describing the actions performed in a piece of code, in places with unobvious logic - pseudo-code
  5. "Talking" names of functions and variables
  6. Macros are not a panacea. It makes sense to use them only if there is some frequently repeated operation, or if at the expense of them you can greatly reduce the code (for example, a macro for an array of strings), but otherwise replacing the usual mnemonics with unusual ones is not an option.

    It is best to split the code into procedures (subroutines), each of which will have a small size (up to 50 lines of code) and perform a logically complete action. These pieces comment and from them collect blocks of a higher level. This is how structure programming was invented.

    • one
      E. Dijkstra in the coffin will not turn from such slander to structured programming? Although, as I understand it, during his lifetime, he had to read and listen to a lot of nonsense about structural programming. - alexlz