• State Not Answered
  • Locked Locked
  • Replies 33 replies
  • Subscribers 22 subscribers
  • Views 7783 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

C runtime environment setup by "#pragma asm"

John Linq

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"?

Parents
  • 0 in reply to John Linq

    I avoid to mention the actual platform, because it is a Fujitsu F2MC-16LX MCU. Sorry for that.

    Hi Per,

    Recently I am quite frustrated. But many thanks for your help, explaining and illustrating.

    Also thanks to all the helps/hints, which I got from this Keil discussion forum.

    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.

    Base on the reading about C51, I suspect that:
    the [startup.c + other C-files] project creates two C runtime environment setup procedules, one is the startup.c itself, another is the other C-files partially invoke the C runtime library of the Toolchain.

Reply
  • 0 in reply to John Linq

    I avoid to mention the actual platform, because it is a Fujitsu F2MC-16LX MCU. Sorry for that.

    Hi Per,

    Recently I am quite frustrated. But many thanks for your help, explaining and illustrating.

    Also thanks to all the helps/hints, which I got from this Keil discussion forum.

    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.

    Base on the reading about C51, I suspect that:
    the [startup.c + other C-files] project creates two C runtime environment setup procedules, one is the startup.c itself, another is the other C-files partially invoke the C runtime library of the Toolchain.

Children
  • 0 in reply to John Linq

    because it is a Fujitsu F2MC-16LX MCU. Sorry for that.

    Yes, you should be sorry for that. For two reasons:

    1) You're holding this discussion in entirely the wrong place
    2) You're working on an outdated architecture. IIRC, Fuji (rightfully) stopped making new versions of that years ago.

    As to the problem in point, I think you should just stop worrying about it. If you really don't believe in that startup code getting the job done properly, compile it to asm and look at what you get. If you're still not convinced, replace the .c file by the generated .asm file and forget about the fact it was ever .C in the first place.

    And yes, I have seen a project using exactly that kind of setup on exactly that architecture, and it's working just fine on millions of devices in the field.