What is the difference between #define and declaring a variable and more

[TheAnalogKid83]

I'm sorry if this question is asked a million times, but I'm trying to see the difference between defining a macro and defining a variable. I know that defining a macro allows for many other things that a variable can't do but I see lots of examples of people doing something like this:

#define twofiftysix 256;

so where ever the program code actually uses this number macro, won't it be essentially be a static variable??

after trying to understand this I start to wonder how a compiler uses just numbers like

int variable;
if (variable > 5) then
{variable = 0;
}

don't the numbers 5 and 0 need to be stored as variables in the memory for them to be referenced while the program is running?

does the compiler automatically generate these numbers as static variables?

 

[Hurkyl]

#define twofiftysix 256;

so where ever the program code actually uses this number macro, won't it be essentially be a static variable??

No. This means "Before you actually start compiling my code, every time you see the token 'twofiftysix', replace it with the four consecutive symbols '256;'."

don't the numbers 5 and 0 need to be stored as variables in the memory for them to be referenced while the program is running?

It's at the compiler's discretion. But most computers have an instruction "test if this value is bigger than 5 and do something".

 

[nmtim]

A preprocessor macro is just a text substitution: the right hand part gets substituted for the left hand part before the code gets to the compiler. So any occurrence of the characters "twofiftysix" downstream of "#define twofiftysix 256" gets replaced with the characters 256. It's basically impossible to control the scope of macros like this, so many code projects ban them.

The literal numbers in your code might be stored in the static section, or they may be encoded directly into the instruction. For instance, you might see something like "movl $0, eax" in the assembly. Depends on compiler, instruction, and ISA.

 

[TheAnalogKid83]

It's at the compiler's discretion. But most computers have an instruction "test if this value is bigger than 5 and do something".

That seems like such a specialized instruction call . . you'd literally have millions of unique instructions just for the sake of comparing a variable to X number and do something. I doubt RISC processors would have anything like that. I'm asking how is the # 5 referenced in this conditional in the actual compiled code?

t's basically impossible to control the scope of macros like this, so many code projects ban them.

Sadly the devkit I'm trying to write code for has atleast a thousand #defined macros and I am so lost on where to start. Its really annoying trying to understand what they're doing when their macros are cryptic or atleast not obvious unless you have a lot of experience with this processor.


It seems they are initializing registers and stuff . . so I'm not sure what I should touch and what I shouldn't. Then when it comes to accessing ports and registers, I have no clue how to. I've always written my C/C++ programs as desktop applications that basically ran in the dos shell on windows xp. The only way I'd know about registers and stuff like that would be from learning assembly and computer architecture. I feel it was a real weakness in my school's program to tie the high level abstract C to the low level workings of a compiler and using the actual specific processor :[

 

[TheAnalogKid83]

That seems like such a specialized instruction call . . you'd literally have millions of unique instructions just for the sake of comparing a variable to X number and do something. I doubt RISC processors would have anything like that. I'm asking how is the # 5 referenced in this conditional in the actual compiled code?

Now if I think about it in terms of assembly, I see that the same thing is done, the number is just one of the parts of the assembly instructions like cmp address, #5;

So I think I understand now.

 

[Hurkyl]

Sadly the devkit I'm trying to write code for has atleast a thousand #defined macros and I am so lost on where to start. Its really annoying trying to understand what they're doing when their macros are cryptic or atleast not obvious unless you have a lot of experience with this processor.

Some compilers offer you the option to display the output of the preprocessor -- that is, the text file that results after executing all of the "#something" commands. In gcc, I think the command line option is -E.

 

[jim mcnamara]

Some compilers may use a separate standalone preprocessor. Example: cpp myfile.c
will show you all of the expanded macros.

Read the man page or compiler docset to see.

 

[rcgldr]

A common optimization on many cpu's for the compare and optionally set a value is to do a compare that sets or clears the carry bit, then do an arithmetic shift right that includes the carry bit so that the register becomes all zero bits or all one bits, followed by a binary "and" instruction to set or zero a value, and then add a constant if needed. In 4 instructions, without any brances or conditional code, you do a compare that results in any two values based on the compare result. Typical of "clever" code in optimizing compliers.

Regarding macros for I/O ports, I find it fairly common place. Generally the macro name will match the port name as described in a hardware document. It will include the size of the port (8, 16, 32, 64 bits), as well the physical address of the port:

// UI32 is a 32 bit unsigned int
#define PORT0 ((UI32 *)0xffff1248)
...

readportvalue = PORT0;
PORT0 = writeportvalue;

...

Depending on the CPU, sometimes a series of port accesses can be optimized if a base port can be used to limit the number of bits required to access ports that are a fixed offset (+/-) from the base port or by locacting the memory map ports near the end of the address space.

Also once a set of port macros are defined, they are re-usable for other projects. Some hardware manufacturers will supply a set of macros for all their port accessing.