#include of C file and listing/emulation

I have several very long subroutines, 1500+ lines each, which consist of 20-50 discrete portions. For stack purposes, I don't wish to make subroutines out of each portion, but for clarity I wanted to separate the portions. I moved each portion, typically the body of an if or while loop, into its own .c file and #included them in place, changing

if (a > 100) {
statement1;
statement2;
...
statement 50;
}; // if


into

if (a > 100) { ; main.c, line 30
#include body1.c ; main.c, line 31
}; // if ; main.c, line 32

with file "body1.c" containing the statements, without any subroutine syntax.

statement1; ; body1.c, line 1
statement2; ; body1.c, line 2
...
statement 50; ; body1.c, line 50


The compiler does what it is supposed to do as far as the executable is concerned; it generates the correct opcodes as if it were all inline in a single file.

The problem I have is with emulation, but the reason can be seen by looking at the generated list file. The line number information for the included .c files is inappropriately constructed. In the above example, the listing file attributes the HLL statements to main.c, lines 30, 1, 2, ..., 50, 32. What would be desired would be to attribute them to main.c line 30, body1.c lines 1, 2, ..., 50, and then main.c line 32.

When enulating, the debug information for HLL presents lines from the parent file, instead of from the included file, making it difficult to debug within the included files.

Has this been seen before? Is there anything that I can do? Is there anything that you can do?

Parents
  • "I have several very long subroutines ... For stack purposes, I don't wish to make subroutines out of each portion"

    A function's stack usage has nothing to do with its length!
    In fact, C51 doesn't even use the stack for locals nor parameters.

    "...typically the body of an if or while loop..."

    this suggests to me that your function calls aren't even deeply nested - so you should have no stack worries at all!

    I think your function aversion is misguided - try it and see!

    "Has this been seen before?"

    Yes - this is the way the preprocessor works.
    The preprocessor does its work before the compiler ever gets to see your code (hence "pre-") - so the compiler doesn't actually know what came from #included files & what came from your "main" source file.

    "Is there anything that I can do?"

    Not if you insist on doing this!

    Another (one of many) reason to use proper functions!

Reply
  • "I have several very long subroutines ... For stack purposes, I don't wish to make subroutines out of each portion"

    A function's stack usage has nothing to do with its length!
    In fact, C51 doesn't even use the stack for locals nor parameters.

    "...typically the body of an if or while loop..."

    this suggests to me that your function calls aren't even deeply nested - so you should have no stack worries at all!

    I think your function aversion is misguided - try it and see!

    "Has this been seen before?"

    Yes - this is the way the preprocessor works.
    The preprocessor does its work before the compiler ever gets to see your code (hence "pre-") - so the compiler doesn't actually know what came from #included files & what came from your "main" source file.

    "Is there anything that I can do?"

    Not if you insist on doing this!

    Another (one of many) reason to use proper functions!

Children
More questions in this forum