• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 22 subscribers
  • Views 3238 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

Leading underscore in variable name

HenkvW

Hi,

I try to investigate a program written by a former collegue.

An 8-bit dipswitch is connected to the microcontroller address/data bus. Two variables are declared in an assembler file: public DIPSWITCH and public _DIPSWITCH. The dipswitch value is read bij an assembler file from address DIPSWITCH (the real hardware address) and stored in _DIPSWITCH. (_DIPSWITCH is to be used as the startup dipswitch value and DIPSWITCH is used as the real actual value).
In a .C file both DIPSWITCH and _DIPSWITCH are declared as 'extern xdata unsigned char'.
If I evaluate the startup value _DIPSWITCH in that .C file I get the actual value of DIPSWITCH.
If I create only two code-lines:

 if ( _DIPSWITCH){ do something}
 if (  DIPSWITCH){ do something}


and then I compile that source with '#pragma src' and look in the listfile I see:

 MOV DPTR,#_DIPSWITCH
 MOV DPTR,#_DIPSWITCH

So both different .C source lines compile to the same assembler code.

Can someone explain this?

Thanks

Henk

Parents
  • 0 in reply to erik malund

    Seems like I would have to spend time with the bible - does it really has the answer to this? - because I find this a bit curious.

    The C compiler should normally add a leading underscore on all symbols with external linkage, i.e. symbols that may be shared between separate compilation units, so a variable DIPSWITCH in C would be mentioned as _DIPSWITCH when linking with other object files.

    This allows startup and runtime library files to use variables without a leading underscore, without creating a name-space collision with end-user application code.

    For a "normal" assembler/compiler, the assembler symbol DIPSWITCH would not have been acceccible in C, unless you used a special compiler switch to request that no leading underscore should be added.

    For a "normal" assembler/compiler, the assembler symbol _DIPSWITCH should have been accessible in C using the name DIPSWITCH.

    That both DIPSWITCH and _DIPSWITCH in C got translated into _DIPSWITCH in assembler sounds like a Keil-specific feature, unless the 8051 bible has any section about special treatment of leading underscores for the 8051 target platform.

Reply
  • 0 in reply to erik malund

    Seems like I would have to spend time with the bible - does it really has the answer to this? - because I find this a bit curious.

    The C compiler should normally add a leading underscore on all symbols with external linkage, i.e. symbols that may be shared between separate compilation units, so a variable DIPSWITCH in C would be mentioned as _DIPSWITCH when linking with other object files.

    This allows startup and runtime library files to use variables without a leading underscore, without creating a name-space collision with end-user application code.

    For a "normal" assembler/compiler, the assembler symbol DIPSWITCH would not have been acceccible in C, unless you used a special compiler switch to request that no leading underscore should be added.

    For a "normal" assembler/compiler, the assembler symbol _DIPSWITCH should have been accessible in C using the name DIPSWITCH.

    That both DIPSWITCH and _DIPSWITCH in C got translated into _DIPSWITCH in assembler sounds like a Keil-specific feature, unless the 8051 bible has any section about special treatment of leading underscores for the 8051 target platform.

Children
No data