Is there any way to declare a symbolic constant as 'an external number' in Keil C51 source code so that the compiler generates object file using instructions with # symbol prefix (e.g. mov r0,#symbol) and therefore the value of this symbol can be supplied on the linker level (from another obj file, where the symbol is given a value and declared as public) ? (Including file with #defines into the source code does not solve the issue - symbols must be defined at the compile time.) Note: in assembler it is easy ... file1.a51 : (file1.obj defines particular values of needed constants for a concrete project)
... public SYMBOL SYMBOL equ 5 ...
... extrn number (SYMBOL) ... mov a,#SYMBOL ...
I don't think so. Remember, the Linker deals with addresses - not values; but there might be a clue there...
you can use a include file
... #define number 5 /* my number */ ...
"you can use an include file" - Yes, I know that feature, but this is not the point. You haven't understood my query well, maybe you haven't read it carefully, I'm sorry. Thanks anyway. Stan
Hi Andrew, "I don't think so..." - probably you are right (what a pity :-), I've thought it as well but I'm still not sure. In my opinion, the linker does not deal with addresses but with "numbers" associated with attributes - data(address), idata(address), xdata(address), ... and number. The attributes provide the linker with necessary information, so it can handle the numbers appropriately and can check their right use as well. If there is at least one assembler module with the equ directive used in a project, then you can find lines like:
VALUE TYPE NAME ------------------------------ N:0002H PUBLIC PADDRESS N:FF90H SYMBOL BFUX10000H
NAME ....... USAGE MODULE NAMES ---------------------------------------- ADST_NONE .. NUMB; REG3_30 BLNK_AD
In C++ this is possible by declaring an item 'const'.
CPP int const thisInt = 0x4893; HPP extern int const thisInt;
"The compiler/linker then can decide" that'd be a problem - he needs to be able to specify this, not just hope that the compiler happens to do what he wants!
Since Keil is a 'C' compiler the point is moot. In the '167 and '251 tool chains there is an 'ASSIGN' command for the linker. I'm not sure if it is in the '51 tools. Usage is; 'C' file
extern unsigned char symbol_Var; { ... unsigned int destination_Var; destination_Var = _sof_( symbol_Var ); ... }
L167 ... ASSIGN( 'symbol_Var' (0x1234))
MOV R4, #1234h
This will work. extern char idata* c; #define symbol_c ( (char)(&c) ) void main( void ) { char C = symbol_c; }
extern char idata* c; #define symbol_c ( (char)(&c) ) This will work if you can create 'c' at a specific address in another module. How do you do this in C? I think you could create a separate module for each variable and use the section/class controls of the linker to put it in a phantom RAM location but it would be confusing, hard to document and maintain. Is there another way? Thanks
I think Scott is true. Your suggestion looks (at the first sight) as if it solved one half of the issue - the compiler generates instructions like 'mov a,#...'. But remember that 'c' is declared as an external pointer to idata (or anywhere else). Then it should be defined as a public item in a different C module and what is important - initialized to an arbitrary required value. However, this is normally linker's job. What is wrong - the item is not a simple number then, it occupies some space in memory. (This second half of the problem can be solved defining and 'publishing' symbol 'c' in an asm module using equ statement, linker is then satisfied with the value and won't use any memory space for it. It's a bit violent but one of my colleagues says "a little bit of violence is not any fascism yet" :-) Nevertheless, I have been interested in purely C-based solution - if it exists... Stan
Sorry, I was replying to your orignal question of generating a "mov r0,#symbol" where the symbol is supplied on the linker level. I just assumed you had a assembly program that generated these constants. I know of no standard "C" way of doing what you ask. The only way I know is ugly. You have to export the constant as an address. The following will export the constant 0x1234.
char xdata symbol _at_ 0x1234;
char xdata symbol[] _at_ 0x1234;
I have seen that sort of trick used by a Client before; not only was it non-portable, but it was also very poorly documented! In the particular case I'm thinking of, the Linker did assign a symbol address rather than a value - which just added to the confusion, as the source code wanted a value! This particular Client also used the cunning trick of passing their Linker command file through the 'C' preprocessor before actually giving it to the Linker - thus enabling them to use 'C'-style symbolic definitions, instead of "magic numnbers" in the Linker command file! This was also undocumented and, needless to say, the whole tangled web took several days to unravel! What I'm saying is: if you really must resort to such tricks, please ensure that they are lucidly documented - preferably as comments directly in the files, rather than some separate "document" which will just get lost and/or out of date. But then, if people did that, they wouldn't need to hire people like me to sort it out later ... ;-)