This is something that would probably give a pretty reasonable speedup in certain cases with a simple change to the compiler.
Currently, constant globals are secretely normal globals with a special flag set that prevents any assignments to them (I'm not even sure if the interpreter checks this flag at runtime), instead, global constants could be resolved at compile time as they're guaranteed to never change.
This should apply for any value that can fit in a 5-byte specifier (everything except for lists)
ID:1522358
 Mar 19 2014, 8:24 am (Edited on Mar 19 2014, 8:42 am)
|
|||||||
| |||||||
|
Mar 19 2014, 1:06 pm
|
|
Lummox JR
   |
This actually could break some games, as the savefile format allows the vars to be saved in their original form, as constants.
|
I specificaly said global constants, not the on-object ones, there are other reasons those could break games, but global ones are pretty much immutable
| |
I've used global constants this way before in Incursion, so it's something that could show up in certain games.
| |
I'm not exactly sure what you're saying, its possible to write to global constant variables? If thats the case, you should probably reconsider the name constant
Otherwise there isnt any problem with this | |
Nope, you still can't write to consts. But what happens is, when the var is saved in a savefile (or map!) it may be saved as its name instead of its value.
For savefiles there's a certain logic in this: The var can work even if the game changes the meaning of any of its consts. Now that being said, as far as code generation I entirely see your point: if the const var does not hold an object, the direct value could be used instead. | |
Of course the original constant would still be in its place, so basicaly what you said, I'm not sure about the implementation but in theory you could find the code that emits get instructions to globals and add some checks there
| |