How does CONST compile?
BlitzMax Forums/BlitzMax Programming/How does CONST compile?
| ||
| When I create a numeric CONST in BlitzMax, is that const compiled as a numeric literal? I mean: const Number1=4534 const Number2=5345 const Number3=5345 If I never use Number1 in my code, will Number1 be using memory, or just ignored by the compiler? In other words, does the compiler 'substitute' every Number1 occurence with its value or it's treatened as a variable? In addition, what does happen with an abstract type full of const? I mean something like: TYPE Keys abstract Const Enter = 13 Const Escape = 27 Const Tab = 9 End Type Will this type declaration be using memory if I declare it in my code, but never use it? there aren't any methods or functions of fields, just const... |
| ||
| I am guessing it puts that number into the actual code. There are CPU instructions that take `immediate data`, ie the number may actually be incorporated into the instruction code itself, or immediately followed by it. I would presume this is how constants compile down - ie the number appears at any place where it is used, stored right next to the instruction that uses it. That is, unless BlitzMax does it some other way. |
| ||
| No, you're right. Any Const variables are replaced by their value at compile time, so 'Const number=5;a=6*number' is exactly the same as 'a=6*5', which in turn gets compiled as a=30. Any mathematical operations that can be determined at compile time, are. |
| ||
| for better understanding: blitz put all constants after start to your memory. And it do not replace "number" to a numeric value. But number is a "pointer" to this memory-adress, so that you have all time eaqal values... |
| ||
| Paul and Toby are correct. Constants do not "use memory" as they are hardcoded into your program as immediate values at compile time - that's why you can't change them at runtime. More importantly however constants do not have to be seperately fetched from memory, but are loaded into the CPU instruction pipeline, during the initial instruction fetch. Check the assembly output if you're in doubt. |
| ||
| Little addition: for string constants that may be very different. They have to be stored somewhere, and it's not guaranteed at all that the compiler elminates unused string constants. As for the type issue, same problem: declaring the type means the implicit creation of some support code, the question being wether the compiler eliminates it if unused. But the real question is: does that really matter? You won't be losing much memory in any case, so it's highly unlikely that it will make the slightest difference to your program. |
| ||
| Check the assembly output if you're in doubt. how would you go around doing that? |
| ||
| how would you go around doing that? BMax creates a .bmx folder in the same location as your source file, inside that there is a .s file, that is the assembly output. |
| ||
| You technically can change the constants at runtime, it's called self-modifying code, which I kind of think is sometimes a good thing, but is more and more taboo these days, if not outright disallowed by the o/s. |
| ||
| The problem with self-modifying code (well ONE of the problems) and changing consts at runtime is that chances are you're using the same const litterally hundreds of times, and so would have to do the same when changing it - making it much slower than using variables. |
| ||
| Errr, why would it be slower? Either it's a type-1 const, in which case you won't be able to take it'as address and modify it in the first place, either it's a type-2 and then (provided it's stored in writable page - don't count on that) it's just a bunch of memory as any other variable. Anyway, in any case attempting to fool the compiler and modify a const sliiiiighly defeats the purpose I dare to say... |
| ||
| When I was working at a Real Games Company the programmer had something that let him recompile sections of code while the game was running. It was the coolest damn thing I've ever seen. |
   |