Hi, i am interested in knowing if the C51 compiler is able to define initrisic functions... I mean if there is a way I can define a function that is expanded inline in the assembly language and there are no CALLs or RETs generated for it. I know there are some built in intrisic funtions in C51 like _iror_ _irol_ and the like, but i wonder if it is possible to define new ones. Any informations on this?
Erik, sorry for the line continuations in the macro definitions in my previous post, the html interpreter got them literally and the macro definitions came out in very long lines... next time i will remove them.
ANY program will have a .h file for the globals, so - again WHAT BURDEN? Erik
Sorry, my variables T1RLL and T1RLH are only needed in module file1.c, then there is no need at all to declare them in a .h file, with the exception that my macro definition 'init_timer1' would be used in a module different from file1.c. If we change this macro definition for a function then there is no need to declare the extern T1RLL and T1RLH and i can still call the function from any module.
Sorry, my variables T1RLL and T1RLH are only needed in module file1.c, then there is no need at all to declare them in a .h file You HAVE to declare them, why is it more difficult to do it in a .h file?? Erik
I normally define global variables in a .c file, if this will be the only module where i will use them then I wouldnt declare them in a .h file. I put in a .h file only those symbols that I would be referring to from different modules. To define a variable in a .h file is not good practice as the risk for multiple public symbols definition arises inmediatly. Nestor.
not if you use the 'no mistake possible' header files. See my posts at the "global variable/MULTIPLE PUBLIC DEFINITIONS" thread. Declaring variables in one place and defining them in another is asking to be caught in mistakes. I am uttely amazed about those that object to this method and, at the same time, insist that the definitions of functions .h file be included where the functions are defined to avoid mistakes. Erik
"not if you use the 'no mistake possible' header files." Unless, of course, you make a mistake in your preprocessor magic...! ;-) "Declaring variables in one place and defining them in another is asking to be caught in mistakes." Not if you include the header with the declarations into the file with the definitions - as I always suggest. If you do happen to make a mistake in your preprocessor magic with the 'no mistake possible' header files, the compiler will never know because it never sees both the definition & the declaration and, therefore, cannot detect if they don't match.
The key point here is that extern definitions in a .h make the symbol public. This clutters up your namespace, and, since C has only one level of naming hierarchy, allows the possibility that some module might start using a variable it really shouldn't. If the variables stay in the .c (file scope static), then the names are not externally visible, and the linker will reject any attempt to use those variables. You ideally should put only the intended public interface to a module in the .h file. You wouldn't generally put private globals in the .h. In this case, the macro definition references these variables, which forces them to become public, which forces them into the .h file. A function definition can keep the variables (and implementation) private. If the function is simple enough to pass parameters in registers, the overhead of the call itself is pretty minimal. (Typical implementations of inline can't handle complex functions anyway.)
I totally agree with Davis & Neil. My personal taste is to avoid conditional compilation as long as it is possible. And in this case is definitely not necessary. Avoiding the declaration of unneeded public symbols is important to avoid cluttering the namespace and to keep private things private. Regarding the inline functions, i have already digested the fact that our Keil C51 doesn't support them 'at least up to now' even though yesterday night i was hoping to find a way to define such type of functions. Then I will stick to my preprocessor macros where readabilty and speed are important and I will continue using functions when they aren't a priority. Nevertheless, if there is anyone there expert on compilers design, and to extend this discussion to a more fruitful point, do you think it would really pose a big problem to include this feature (inline funtions) in the c51 compiler? My guess is that it wouldnt be very complicated. Nestor.