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

How to fine tune a piece of C code into macro?

I have a piece of C code,


if(u3Varaible0 > u3Variable2)
{
#ifdef DEF_SOMETHING
.
.
#else
.
.
#endif
}
else
{
.
.
.
}


The variable length of u3Varaible0 is 3 bytes. I don't want to declare it as "unsigned long"(inorder to save onchip memory and reduce execution cycles), So I have to write this piece C code into asm code look like


CLR C
MOV Au3Varaible0_L
SUBB A,u3Variable2_L
MOV Au3Varaible0_M
SUBB A,u3Variable2_M
MOV Au3Varaible0_H
SUBB A,u3Variable2_H
JC C0049
.
.
.
.
C0049:
.
.
.


I want it be a macro(inorder to reduce execution cycles).
But now comes the problem:
1.
If I write this code as a asm macro in an asm source. I just can't use this macro from a C code.

2.
If I try to write is as C macro using #define, It is impossible to use inline assembly in the macro!!

3.
#ifdef DEF_SOMETHING
will also cause an error in #define macro


Does anyone know another good way to solve this fine tune problem?

Parents
  • Hi thanks to all.
    Execuse me. My main purpose is not to solve
    3 bytes length variable problem. It is just an example.
    I'm trying to focus on how to sove the following three problems.

    1.
    If I write this code as a asm macro in an asm source. I just can't use this macro from a C code.

    2.
    If I try to write is as C macro using #define, It is impossible to use inline assembly in the macro!!

    3.
    #ifdef DEF_SOMETHING
    will also cause an error in #define macro

Reply
  • Hi thanks to all.
    Execuse me. My main purpose is not to solve
    3 bytes length variable problem. It is just an example.
    I'm trying to focus on how to sove the following three problems.

    1.
    If I write this code as a asm macro in an asm source. I just can't use this macro from a C code.

    2.
    If I try to write is as C macro using #define, It is impossible to use inline assembly in the macro!!

    3.
    #ifdef DEF_SOMETHING
    will also cause an error in #define macro

Children
  • 1. This seems reasonable, if inconvenient, since the assembler syntax is not understood by the compiler, any more than the assembler understands C function call syntax.

    2, 3. ANSI C prohibits a preprocessor macro (#define) from generating further preprocessor directives. So a #define can indeed not expand into a "#pragma asm" or "#if defined()". (This restriction is one of the more awkward points about trying to play nice and use the standard #pragma syntax, instead of adding extension keywords or the GNU-ish __attribute(foobar).)

    The easiest way, IMO, to link C code with assembler code is to write subroutines in assembly that conform to the C calling conventions. Then add extern definitions to a header file, #include that header, and call the function as normal.

  • "1. If I write this code as a asm macro in an asm source. I just can't use this macro from a C code."

    Here is your fundamental problem: 'C' and assembler are different languages; they have different semantics and different syntax rules. It should therefore come as no surprise whatsoever that assembler source does not work in 'C', and vice-versa

    Write 'C' source code in your 'C' source files, and assembler source code in your assembler files.

    If something needs to be written in assembler, then write it in assembler in an assembler source file.

  • So,the conclusion of this topic:
    If we have a routine in assembly code and want to use it at many playces from C code. Function call is always necessary, macro is impossible. There is no way to save "push and pop program counter" instructions.

  • "If we have a routine in assembly code and want to use it at many playces from C code. Function call is always necessary, macro is impossible."

    Correct.

    "There is no way to save 'push and pop program counter' instructions."

    If this is a real problem to you, then you should be writing in assembler anyway.

    Just extend your assembler function so that it encompasses all the bits that need to use this macro - and call this larger function from 'C'.
    Thus you can use your assembler macro in its proper environment (an assembler source file), and only have one call/return overhead from 'C'.

  • If this is a real problem to you, then you should be writing in assembler anyway.

    I do not know what is happening, but recently there has been a swarm of posts "why can C not do what assembler can".

    Hey Guys, if you want the pleasure of C, do not complain about the pain.

    It is emminently possible and practical to mix C and assembler files but do not attempt to mix C and assembler statements

    Erik

  • If this is a real problem to you, then you should be writing in assembler anyway.

    I do not know what is happening, but recently there has been a swarm of posts "why can C not do what assembler can".

    Hey Guys, if you want the pleasure of C, do not complain about the pain.

    It is emminently possible and practical to mix C and assembler files but do not attempt to mix C and assembler statements

    Erik

  • Erik said,

    "It is emminently possible and practical to mix C and assembler files, but do not attempt to mix C and assembler statements"

    An excellent way of putting it!