• State Not Answered
  • Locked Locked
  • Replies 18 replies
  • Subscribers 21 subscribers
  • Views 7826 views
  • Users 0 members are here
2025 survey

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.

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

Using conditionals within shared (C & ASM) header file

Steve Mutschler

Last June, someone asked about how command line symbols defined for both the assembler and the C compiler could be referenced within a conditional (if) statement within a universal shared header file. A company rep said they'd forward this to the tech team for advice. Whatever happened?

The issue is this: Symbols of identical name specified on the command line for the assembler and the C compiler end up being unique symbols. Those specified for the assembler are defined as per a "$set" directive and are visible only to the assembler. Those specified for the C compiler are defined as per a "#define" directive and are only visible when running the compiler.

In other words, there is no way to define a symbol on the A51 assembler command line that will be visible to the C preprocessor within the assembler. Symbols defined this way are only visible to "$if" statements.

PROBLEM: A universal header file containing an "#ifdef SYMBOL" conditional branch will work within C modules, but will not work within assembler modules because the assembler's C preprocessor WILL NOT recognize the referenced symbol and will thus test false.

Example:

#ifdef SYMBOL
  #include <me.h>
#endif
will test as false within the assembler C macro preprocessor if SYMBOL is only defined on the command line. Of course, an explicit
#define SYMBOL
appearing before the conditional will force the condition to be TRUE, but that is not what we are trying to do here. We want the command line argument to trigger different code versions, for example, to target different hardware configurations.

So it's 2005. Any solutions to this dilemma yet?

Parents
  • 0

    How about running the .h file through the preprocessor (only) with the command-line option of your choice, and then feeding it to the assembler?

    It's not obvious to me that the COND/NOCOND directives are exactly what you want. But there's always a standalone preprocessor like GNU cpp.

Reply
  • 0

    How about running the .h file through the preprocessor (only) with the command-line option of your choice, and then feeding it to the assembler?

    It's not obvious to me that the COND/NOCOND directives are exactly what you want. But there's always a standalone preprocessor like GNU cpp.

Children
  • 0 in reply to Drew Davis

    Using the gnu preprocessor to generate an intermediate file is a great suggestion and I believe that would work, albeit not as "simple elegant" as we might like. Thank you!

    I was just thinking of another approach. I am going to attempt this, but might it be possible to define an assembler level macro that could be used within the header file to generate alternate "code" (i.e. text) based on whether or not the assembler is running? I believe there are predefined symbols that can be tested to determine if the C compiler or the assembler is running...

    To be continued...

  • 0 in reply to Steve Mutschler

    P.S.
    For interested parties, the way we are handling this issue today is to maintain essentially identical ".inc" and ".h" files for the desired headers, thus, totally defeating the desire to maintain a SINGLE header file.

    The "GIZMO.inc" files are included in assembler modules and the "GIZMO.h" files are included in C modules. The ".inc" contains '$if' logic (and '$include', etc.) and the ".h" contains '#ifdef' logic and (and '#include', etc.)

    This is obviously suboptimal and mistakes happen.