An example would be, "To compile your source file execute the following (.com, .exe, or batch) file" since this is running under DOS. "This will produce the following output files." (followed by a list of output files and where they are to be found). "In order to assemble the compiler output, type the following command" (followed by a command or list of commands, arguments, and switches). "In order to simulate the assembled compiler output file, type the following command(s)" (followed by a command or list of commands, arguments, and switches). If source-level simulation is supported, then that should be handled similarly.

I don't doubt that SDCC has all these features or the lack of them, described somewhere. I wouldn't be complaining about this matter if I hadn't, for some time, been trying to find this sort of information. The problem is that it isn't in one place, and that, being in different places, and having different references, it is sometimes self-contradictory.

Try approaching this from the standpoint of a recent graduate who's learned how to compile "Hello World" but hasn't gone far beyond that, and understands little or nothing about compiler design. The guy might be an excellent mechanical engineer trying to devise a simple MCU-based thermal (or whatever) management subsystem for his machine. He doesn't want to spend weeks searching for information that would occupy a page or less if it were located in one place. He dosesn't want to learn about the obtuse characteristics of his particular OS. He doesn't even care how wonderful or efficient the tool is. He certainly does't want to peruse thousands of lines of code just to find out how to use it. He wants to use the tool set. It would be really helpful if he could find precise, up-to-date, specific and step-by-step, instructions on how to use the tools.

RE