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

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

  • Can someone explain this?
    sure, but to no avail.

    you need familiarize yourself with the chip or you will be lost after the next step.

    read "the bible" (in this case, especially ch2)

    erik

    here are the links to "the bible"
    Chapter 1 - 80C51 Family Architecture:
    Chapter 1 - 80C51 Family Architecture:
    www.nxp.com/.../80C51_FAM_ARCH_1.pdf
    Chapter 2 - 80C51 Family Programmer's Guide and Instruction Set:
    www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf
    Chapter 3 - 80C51 Family Hardware Description:
    www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf

  • 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.

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

    That's not a program. It's a trick question only superficially looking like a program.

    You need to start with understanding that hardware. What exactly do you think will happen if you connect a bank of switches, of all things, where a RAM chip is supposed to go? Can such a crazy piece of nonsense really behave like memory?

    In a nutshell, you've been had.

  • "That's not a program."

    How can you say that? He hasn't posted any program for you to classify.

    "What exactly do you think will happen if you connect a bank of switches, of all things, where a RAM chip is supposed to go?"

    If the memory interface pins are also usable as generic I/O pins, then the OP probably expects to be able to read the DIP switch state.

    "Can such a crazy piece of nonsense really behave like memory?"

    It doesn't have R/W and strobe signals, but yes - it is a one-byte memory. Do you see any problem with connecting a 8-bit DIP-switch to a 8-pin interface on a microcontroller? The OP never said anything about expecting it to behave as a flash, EEPROM, RAM, ... memory.

    All the OP has said, is that he wants to read the initial value of the DIP-switch and store in one value, and he wants the current value of the DIP-switch to be stored in the second variable. With a bit of optimization, he could of course skip the second variable and use his physical DIP-switch as a read-only memory variable ;)

  • Look in the C51 Manual in the section about interfacing 'C' to assembler - that contains a lot of detail about the compiler's internal naming conventions...

  • The manual discusses a leading underscore for function names, sepending on calling convention. I didn't see anything about treatment of underscores for variable names.

    The use of name mangling of symbols is normally there to allow the linker to perform type-safe linkage or to create private namespaces for RTL or startup files. It is normally not intended that multiple C symbols should end up mapping to the same ASM symbol.

    Normal type-safe linking is only applicable to C++ and not to C, but the 8051 brings the additional problem of keeping track of which memory region a symbol is stored in.

    By the way - "internal naming conventions" is not so "internal" if multiple C symbols results in a name collision.

  • He hasn't posted any program for you to classify.

    He posted fragments of that program, and enough of a description of the rest of it, to allow that classification.

    If the memory interface pins are also usable as generic I/O pins, then the OP probably expects to be able to read the DIP switch state.

    He's not treating it as generic I/O though.

    The OP never said anything about expecting it to behave as a flash, EEPROM, RAM, ... memory.

    You may want to re-read the OP. That code he was given quite clearly told the compiler that this is supposed to be memory (an unsigned char in xdata space, to be precise).

    As-is, it's about as likely to kill the micro by short-circuiting unprotected output pins as it is to do anything useful.