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"?
"What will be the side-effect, when the C runtime environment is setup by the C extension "#pragma"?"
probably none.
as far as the mcu is concerned, it simply executes a series of commands sent to it. what generated those commands is irrelevant.
as to the wisdom of using .c start-up files, check the cmsis document and you will see that they plan to use .c start-up files later.
no, I wouldn't lose too much sleep over that.
CMSIS applies specifically to ARM Cortex-Mx, and one of the key goals of that architecture's design was to allow "all C" coding - in particular, witout requiring assembler startup code.
The 8051 is very different!
That's why I said early on that this can't be treated (just) as a generic topic - it does depend very much on the particular toolset!
the cmsis example is to show that there is nothing wrong with using .c start-up code.
and I am not sure why that wouldn't / couldn't be extended to cover the 8051.
Yes, the Cortex really are special.
No __irq keywords for interrupt handlers.
A fixed address for storage of information of the stack, so that the processor can initialize an initial stack on its own.
C is well qualified for low-level tasks.
One thing to care about when having strict C code to initialize a processor is that this init() function don't have access to the full C RTL until it has called a init function available with the C RTL - the call we normally see either directly before our main() is called, or the last call in a normal assembler startup file in case the C RTL init function performs the call to main().
Same thing with zeroing memory and assign of initialized data.
But having the init code in C or assembler is really irrelevant to this specific thread. In this case, we are talking about assembler initialization - but assembler instructions in a C file instead of in a separate assembler file.
This is bad modularization. And potentially, there may be part of the initialization in assembler and part in C, and lots of assumptions about compiler-specific requirements.
When talking about an all-C initialization for a Cortex processor, it would normally be the compiler vendor who supplies a complete system with the required helper functionality in the CRTL, and with a sample startup.c file containing the "normal" initialization steps.
'Yes, the Cortex really are special.'
like what?
"In this case, we are talking about assembler initialization - but assembler instructions in a C file instead of in a separate assembler file."
I am not sure if that (inclusion of assembler instructions in a C file) makes a big difference. end of the day, they produce the same result.
I do see a benefit to create a separate assembler file for those assembler instructions if you have tons of them -> essentially create a .asm start-up file.
but if the amount of assembler instructions is small, it probably makes more sense to include them in a .c file.
my point is that it is hard to make an absolute statement about whether it is right (or wrong) to embed assembler instructions in a .c file. it depends on many other factors.
Both of these are major risks to you / your project / your company - I'm not sure which is worse!
To me, the worst case is, people here think that: what John Linq did well is due to those things are simple; And what John Linq failed to do it well, is due to John Linq's fault.
Hope this worst case would not happen. I guess I have to be more positive. Since I don't have choices, and I am being paid to handle this.
Hi Mike,
. As long as the environment is set up properly, it doesn't matter if it's a .s or a .c file.
May I assume that, you have seen several cases, where the C runtime environment is set up properly by "#pragma asm"?
"like what?"
Already covered in previous posts.
View all questions in Keil forum