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

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

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

Children
No data