JASS: Constness and Inlining questions

04-08-2006, 01:17 AM

In the Jass Manual it says:

Quote:

If a function declaration is prefixed with constant, like the following:

JASS:

constant function const_func takes integer a returns nothing
     ...
endfunction

then you can not call non-constant functions within the function body. (Nevertheless, note that you can still use the set statement in the body to alter function arguments, so it is not really "constant" in the typical sense; it is more of a hint to the programmer than anything else)

So, I take this means that "constant functions" doesn't really do anything?

With the extended use of functions instead of globals, such as:

JASS:

constant function CoolSpell_DamageOptions takes nothing returns real
    return DamageTypes(ATTACK_TYPE_CHAOS,DAMAGE_TYPE_FIRE)+DamageOnlyEnemies()
endfunction

I wondered whether or not War3 could benefit from inlining? The overhead attached to calling a function in most programming languages are the reason one of the most common optimization techniques is to inline tiny functions to the point of call. Would it be wrong of me to assume Jass also has enough function call overhead to make such an optimization worthwhile?

It would be trivial to replace all calls to "CoolSpell_DamageOptions" with "(DamageTypes(ATTACK_TYPE_CHAOS,DAMAGE_TYPE_FIRE))" using a simple script parser, and it would work for any function that consists of only

Or does any of the mapoptimizers do this already? Hey for all I know, maybe War3 does this when running jass (although I guess not).

How about constant variables? I guess War3 constant cant be changed after assignment, but does anyone have a clue whether or not War3 actually uses constants to form any kind of optimizations such as inlining constant values?

04-08-2006, 02:14 AM	#2
PipeDream	Certainly it could be beneficial. This is called "peephole" optimization, which includes other things such as evaluating arithmetic expressions. Some experiments have been done which suggest that warcraft does not touch the code at all, beyond creating function line tables. The limit on ExecFunc range casts doubt on even that.

04-08-2006, 07:14 AM

karukef

Yes inlining usually does wonders. I was just wondering why no-one has done it before if it has beneficial effects.

But, I guess I can put "make inlining optimizer" on my to-do list. (And if it works out well, maybe also expression evaluation and even possibly resolving const-values.)

Btw, do you have any more information on what kind of experiments have been done and how they indicate that warcraft do not touch the code at all?

04-08-2006, 07:46 AM	#4
RodOfNOD	Well I do have a couple thoughts.. First off if your going to optomize make it so its a REAL constant like constant integer x = 45 My biggest question though is does blizzards compiler that runs before the game starts, actually do that for you? Ie does it do its own inline code? I would doubt that they are that good but who knows....

04-08-2006, 07:53 AM	#5
PipeDream	I think what I would have, rather than a complicated to write optimizer, is a macro/preprocessing engine. Run on map file before running, swaps out //#define or something silly like that. Someone else can probably think of a better syntax than me.

04-08-2006, 08:57 AM

karukef

@RodOfNod: Yes, that is the exact same question I myself wish I knew: How exactly does War3 interpret and run jass code?

Much points to "not a whole lot"

@PipeDream:

An inliner is easy to write actually.

0: Tokenize the script to isoloate expressions. (rather simple in Jass)

1: Find all functions that consists of a return expression. (That is, all functions that merely "return expression"

2: Replace all references to this function within expressions with that single line expression, interpolating argument calls.

So if you have

JASS:

function SpellDamage takes real level returns real
    return 20*(level*level)
endfunction

function DealDamage takes real whichLevel returns nothing
    local real amount = SpellDamage(whichLevel)
    ...
endfunction

the parsing would be as simple as replacing to get this:

JASS:

function DealDamage takes real whichLevel returns nothing
    local real amount = 20*(whichLevel*whichLevel)
    ...
endfunction

Sure, a macro and preprocessing engine can be useful. Although that is something else than optimizing. Having one does not make the other less useful.

I already do quite a bit of such preprosessing already, being lucky enough to be quite proficient with Python. For example, this is a function that is called when the ability with rawcode '$204' is used by a unit:

JASS:

function ABIL_Malignant_Resolve takes nothing returns nothing
    //! OnAbilityEffect $204
    call DebugMsg("Casting Malignant Resolve through CasterSystem")
endfunction

The '//! OnAbilityEffect' is a command that tells my preprocessor to generate code that creates a trigger, registers the events needed and finally inserts this into an init routine. And as a bonus, it renames all "take nothing return nothing" functions into really short names, because Vexorian's optimizer can't safely do that, but my script can know which ones can safely be renamed.

This is a lot more powerful than a macro processing engine as it can do pretty much whatever I want, but of course, requires programming experience.

04-08-2006, 09:09 AM	#7
Anitarf	As far as I know, Vexorian's optimizer already has an option to inline constant functions.

04-08-2006, 09:15 AM

karukef

@Anitarf: That's what I said: I can't imagine no-one has done this already.

You know, the first thing I did before posting this was skim through the readme for the optimizer, because I assumed it already did constant inlining. But I was probably looking to hard for inlining, when Vexorian describes it under "Remove Useless code" (a section I skipped past because it didn't seem to be what I was looking for) :)

This means Vexorian has yet again done the job for us :)