I am checking some terrible C source code; I haven't got any idea about how to maintain it or cooperate with it. But I found a very fundamental problem. It does NOT have a startup.asm; it has a startup.c using the powerful C extension "#pragma". So, the C runtime environment is setup by "#pragma section", "#pragma intvect", "#pragma asm". I quite worry about such a startup.c; so I contacted the FAE of our local distributor. The FAE is an experienced good engineer, but he told me that, this is not their standard way to setup C runtime environment; they definitely provided the startup.s from Day 1.
What will be the side-effect, when the C runtime environment is setup by the C extension "#pragma"?
But I found a very fundamental problem.
To me it doesn't sound fundamental at all. As long as the environment is set up properly, it doesn't matter if it's a .s or a .c file. File extension doesn't say much about the correctness of its contents. Since you are saying that the code is terrible in other ways, I think that the startup file will be the least of your problems.
As long as the environment is set up properly, it doesn't matter if it's a .s or a .c file.
Hi Mike,
You are right.
But we already know that many global variables are reset unintentionally in some specific cases; this is one of the persistent problems of this project for my colleagues.
This startup.c makes me feel that, the whole environment can not be trusted.
are reset unintentionally in some specific cases
Once the run-time environment is successfully setup, it is setup. This is likely to be the result of a problem in the program itself.
BUT how do you know that the setup was "successful"?!
If the setup is broken, it will leave the system in a broken state - likely to cause problems in later execution.
A classic example is the many C51 posts where the setup is "broken" in that it does not correctly configure the XDATA access...