We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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?
this is continuing development on an existing hardware with I don't know how many thousands in the field. The hardware is set. While new platforms are being developed, this platform is being squeezed to beyond an inch of its life. Designed over five years ago, it uses a Dallas 80c320 running at 33 MHz. The interrupts are all in Assembly, hand coded for speed and code size, using register banks and multiple data pointers. Interrupt stack usage is detailed. Code execution stack usage is detailed. Internal emmory variables are overlain and detailed. At this point, to increase any of their use will require a decrease somewhere else, a sacrifice I am not willing to make unless I must. I am using both code banking and multiple sets of data banking. The #PREPRINT produced .i file looks like it will serve; macros and #includes are expanded to produce a flat file which will allow meaningful debug information and references to source code files. The unsymetry of removing white space, which undoes indentation, while retaining the blank lines after removing comments, does look a little odd.
For what it's worth, the standalone C preprocessor 'cpp' maintains whitespacing and would leave your "flat" file much more readable. Free (i.e., FSF/GNU-ish) and commercial versions are available.
Compiling and linking from the .i file does produce the debug data that I was looking for. It appears that the only way to have the target compile x.c to actively produce x.i, and then compile x.i to produce x.obj causes the linker to attempt to link x.obj twice (compiling x.c produces the x.obj I don't want), which generates a warning. I have not been able to find a way to include it as a compile for the project without also including it as a link for the project. Warnings I can live with.
I have not been able to find a way to include it as a compile for the project without also including it as a link for the project. In uVision2, you can right-click on the source file, select options, and un-select the include in target build. Jon
In which case the x.i does not get remade from the x.c, because you have told it not to use x.c at all.
In which case the x.i does not get remade from the x.c, because you have told it not to use x.c at all. Yep. You are right. Here's another technique that works on my machine. 1. Leave Include in Target Build, Always Build, and Link Publics Only default (grey checks). 2. Check Generate Assembler SRC File. 3. Uncheck Assemble SRC File. 4. Make sure that file.i is included AFTER file.c. This works on my system. Jon