1. 15
    1. 5

      Why would you even write that huge function as inline asm, with zero C code? Just put it in a .s file and you don’t have to worry about all that boilerplate, all those quotes, all those \ns.

      It’s just SO MUCH easier.

      1. 2

        And C23 has #embed now so you can just directly include the .s file

        1. 2

          Huh? Why would you want the literal assembly source in your executable?

          1. 1

            I’d assume it avoids a lot of build system pain when you can make sure that the assembler matches the compiler by simply.. running the compiler.

            1. 1

              Do we assume the compiler is on the target? How do we (re)link with the compiled object? I don’t assume the PlayStation 2 (or PCSX2) can do that.

              Note that, per your parent, #embed literally embeds the target, so that you’d end up with (e.g.):

              static const char sfile[] = "# Clear bss area\nla   $2, _fbss\nla   $3, _end\n…";
              

              Your running program has assembly source available to it.

        2. 2

          Some justifications I’ve seen (although I don’t think they are all that compelling):

          • It’s usually small and devs would rather have the source right there with all the other source.
          • It makes the build simpler (not sure how, but okay).
          • The biolerplate assembly for the function declaration, section directives and so forth are taken care of for you.

          The last one is probably the most compelling reason.

          1. 1

            The most compelling, but not very compelling when it’s a matter of seconds to make a .c with just the function prototype, add a {} after it (and dummy return if required), do gcc -S on it, delete the .c and edit the .s.

            Though just …

                    .globl __start
            _start:
            

            …. will probably do the job too. Maybe a section declaration (it defaults to .text anyway).

            1. 1

              If you have many different architecture targets there might be more involved, depending on the target. (If that’s the case, however, then you should be sure your assembly is portable.) Also, you may want to put it in its own section so you can map it easier in a linker script.

              1. 1

                If you have many different architecture targets then your inline asm is going to have the identical problem.

                Also, you may want to put it in its own section

                Yes, you might. Yet another reason to have it it in a real .s file where that is trivial. It can be done in some C compilers, but that becomes compiler-dependent.

                PLEASE don’t switch sections in the inline asm, behind the compiler’s back!!! I don’t even think you should put control flow (e.g. that clearing BSS loop) in inline asm. That’s just code smell after code smell.

        3. 2

          This seems like a pretty cool trick for underhanded C.

          1. 1

            This is why I write inline asm inside a raw-string instead of many little strings. You don’t need to worry about all the little “ characters and newlines. I think raw-strings are a C++ feature, but maybe C compilers support it too.

            1. 1

              I think the only reason that we use inline assembly comments is to -S output contain comments. In many cases they are probably not that useful and we could just use:

              asm( // nop “nop\n” // nop “nop\n” );